kurodasense

一个参考文献：https://www.cnblogs.com/wiesslibrary/p/16446553.html * TCP 为了保证可靠性，**窗口左边向右滑动时的长度取决于已经确认的字节数**。如果中间出现丢包，就算接收到了更大序号的 Segment，窗口也无法超过这个序列号。 * 而QUIC通过 window_update 帧告诉对端自己**可以接收的字节数**，这样发送方就不会发送超过这个数量的数据，并且通过 BlockFrame 告诉对端由于流量控制被阻塞了，无法发送数据。因此就算此前有些 packet 没有接收到，它的滑动只取决于接收到的最大偏移字节数。

打开f12，然后点击那个简历模板页面，找到其html元素，然后自己手动添加css样式： 

也可以用toString()来转成二进制，然后用parseInt()来转回十进制： * num.toString(radix)：可以将num转为指定radix进制的数。 * parseInt(str, radix)：解析str并返回指定基数radix的十进制整数。 ```js function IntegerToBin(num) { return num.toString(2); } function BinToInteger(bin) { return parseInt(bin, 2); } const bin = IntegerToBin(1023012); const int = BinToInteger(bin); console.log(bin); //...

- **幂等性不同**。幂等性是针对于理想情况下的设计结果。GET 对访问的数据没有副作用，具有幂等性。而当POST 用于**更新**操作时往往是有副作用的，不幂等。 - 因为幂等性的差别： - GET 产生的 URL 地址可以保存为书签，而 POST 不可以。 - GET 请求会被浏览器主动 cache，而 POST 不会，除非手动设置； - GET请求参数会被完整保留在浏览器历史记录里，而POST中的参数不会被保留。 - GET在浏览器回退时是无害的，而POST会再次提交请求。 - **携带数据的方式不同**。 - GET 一般将数据以参数的形式放到 URL 中，虽然...

参考文献：https://www.cnblogs.com/wiesslibrary/p/16446553.html * stream offset * TCP 为了保证可靠性，重传包的包序号和原始的包序号是一致的，这就会导致Tcp 重传的歧义问题。当超时事件 RTO 发生后，客户端发起重传，然后接收到了 Ack 数据。由于序列号一样，这不好判断 Ack 数据到底是原始请求的响应还是重传请求的响应呢。 * QUIC通过stream offset 来确定这个包在这个stream 中的绝对位置，保证了数据的可靠性。并且用一个packet number(保证严格递增)来代替tcp的sequence number。就算 Packet N 丢失了，重传的 Packet N 的 Packet Number 已经不是...

参考文献：https://juejin.cn/post/7166244278551707656#heading-9 performance.timing已经被废弃了，需要使用PerformanceNavigationTiming来计算，其获取可以用： * window.performance.getEntriesByType(navigation)[0] * window.performance.getEntries()[0]