网络协议学习笔记

HTTP 1.0

这是一个最基本的网络协议，基本流程是：

客户端建立一个 tcp 链接
在链接上发起一个请求到服务器
服务器返回一个 response
关闭连接

每次来一个请求都要进行一次连接的开启与关闭，这样子有俩问题

性能很差，因为连接开启与关闭都是耗时操作
服务器推送问题，服务器无法再客户端没有请求的情况下主动向客户端推送消息。但很多情况往往都需要服务器在某些事件完成后主动通知客户端。

为了解决这些问题，开发者们引入了 Keep-Alive 与 Content-Length 的属性

Keep-Alive 与 Content-Length

为了解决第一个问题，http 1.0 设计了一个 keep-alive 机制来实现 tcp 链接复用。具体实现是在请求头上加了一个 Connection: Keep-Alive 字段进行处理。服务器收到带有这种字段的请求时，在处理完请求后不会立刻关闭连接，并在其 response 里的头部也加上该字段，然后在该连接上等待客户端的下一个请求。

当然，服务端能开启的连接数有限，如果连接一直不关闭就会把服务器的可开启连接个数消耗掉，所以服务器还有一个 Keep-Alive timeout 参数，当一个连接上在一定时间内没有新的请求进来时，连接就会关闭。

为了解决第二个问题，开发者们又在请求头上添加了这样一个字段： Content-Length 这个字段告诉客户端 http response 响应的内容有多少字节，客户端收到这么多字节后，就知道数据已经发送完毕了。

HTTP 1.1

从前面的 Keep Alive 的机制中可以看出，连接复用是非常重要的一个机制。所以在 http 1.1 之后，就把连接复用变成了一个默认属性，即使不加上 Keep Alive 字段，服务器也会在处理完请求后不关闭连接，除非请求头显式地设置 Connection: Close 属性，服务器才会显式关闭连接。

在 HTTP 1.0 中可以使用 Content-Length 字段，让客户端判断一个请求的响应是否完整接收，但是这个字段计算对于服务器来说比较困难。

因此，在 HTTP 1.1 中采用了 Chunk 机制。具体来说，就是在响应头上加上： Transfer-Encoding: chunked 字段。目的是告诉客户端，响应的 body 是分成了一块块的数据，块与块之间有间隔符，。所有块的结尾都有个特殊标记，这样即使没有 Content-Length 字段，客户端也能判断出来响应的末尾。

下面展示了一个简单的具有 Chunk 机制的 HTTP 响应：

HTTP/1.1 200 OK
Content-Type: text/plain
Transfer-Encoding: chunked
25
This is the data in the first chunk
1C
and this is the second one
3
con
8
sequence
0

Pipeline 与 Head-of-line Blocking 问题

通过连接复用机制，成功减少了建立连接与关闭连接的开销。但还有个问题，在同个连接上请求是串行的，每次都是客户端发送一个请求，收到响应后再继续下一个请求。这样会导致并发度不够。

因此 HTTP 1.1 引入了 Pipeline 机制，在同一个 tcp 请求上可以在一个请求发出去，响应没有回来之前就发送下一个请求，这样提升了在同一个 tcp 连接上面的处理请求的效率。

不过这种机制有一个致命问题，即 Head-of-line Blocking。原因是：服务器处理请求是并发的，但是客户端接受响应是以队列的形式接受响应，先进先出。如果队列头部的请求发生了延迟，客户端迟迟收不到第一个请求的响应，则会直接堵塞同个 tcp 连接上的所有响应。

为了避免这种问题，大部分浏览器直接把这种机制关闭了。

HTTP 2 出现之前的性能提升方法

有以下四种：

Spriting
内联 (Inlining)
JS 拼接
请求分片技术

一来多回

有以下几种方法：

客户端定期轮询（效率低且增加服务器压力）
FlashSocket / WebSocket （直接基于 tcp，但是有一定局限性）
HTTP 长轮询客户端发送一个 HTTP 请求，如果服务器有消息就立刻返回，如果没有则先保持这个连接，客户端一直等待该请求返回。在服务器内过了一个约定时间后，如果服务器还没有新消息，服务器就返回一个空消息。客户端收到空消息之后关闭连接。再发起一个新的连接，并重复此过程。
HTTP Streaming （即 Transfer-Encoding: chunked）

断点续传

客户端在下载大文件时记录数据量的大小，一旦连接中断并重新建立连接后在请求头上加上 Range: first offset - last offset 字段进行数据区间的指定，就可以获得指定区间的数据，

HTTP/2

二进制分帧

HTTP/2 为了解决 HTTP 1.1 队头阻塞的问题，所设计的特性。

头部压缩

HTTP/2 有一个 HPACK 协议和对应的压缩算法进行头部压缩。

TCP / UDP

众所周知，UDP 传输是不可靠的，而 TCP 是可靠的。什么是不可靠的？

当客户端向服务端发送数据时，有的时候会不可避免地发生以下情况：

丢包（数据包要经过许多的路由节点，其中有的节点发生故障是不可避免的）
时序错乱（每个包都不可能走同一条节点路线到达服务器，因此谁先到与谁后到服务器是无法确定的）

而 TCP 协议是如何做到可靠的？ TCP 可靠的意思如下：

数据不丢包
数据包不重复
时序不乱

而 TCP 就是在不稳定的网络路径上通过各种机制去尝试建立了一个 “可靠” 的网络通道。

接下来看看 TCP 是通过什么机制来做到可靠传输的：

ACK + 重发网络丢包是不可避免的会出现的，如果丢包了该怎么办？重发，服务器每次收到一个包，就对客户端进行确认，告诉客户端已经收到了包，如果客户端在一定时间内没有收到 ACK，则重发数据。
解决不重复问题在上面的情况中，只要超过了约定的时间，客户端没收到服务端的 ACK 时就会进行重发，但有时 ACK 已经在网络上了，只是还没到达客户端，如果客户端重发，服务器就好收到重复的包，就需要判重。服务器怎么判重？之前提到的 ACK 就是一个顺序标记。比如：服务器给客户端回复 ACK=6 ，意思是所有顺序大于或等于 6 的数据包已经收到了，之后凡是再收到这个范围的数据包时，则判定为重复的包，服务器收到后自动丢弃。
解决时序错乱问题假设服务器收到了数据包 1 2 3，回复给客户端（ACK=3）之后，收到了数据包 5 6 7，但是 4 迟迟没有来，那该如何处理？此时服务器会把 5 6 7 先暂时存放着，直到数据包 4 的到来，再给客户端回复 ACK=7，如果数据包不来，则服务器的 ACK 进度会一直留在 3 那里。客户端超时后会把数据包 4 5 6 7 全部重发，到了服务器会通过判重方法去掉重复的包后，回复给客户端（ACK=7）

但是 TCP 真的是 100% 可靠吗？可以看看这篇文章：https://blog.csdn.net/Edward_LF/article/details/124360441

TCP 假连接

从前面的各种操作来看，在客户端和服务端之间并不存在一个可靠的 “物理管道”。只是在逻辑层面通过一定的机制让客户端与服务器之间建立了一个 “可靠的连接”。但并不是真的可靠，只是通过各种机制去保证数据尽量的可靠。

TCP 的三次握手

图上 seq 代表的是发出去的包的编号

初始状态：服务端监听某个端口，处于 LISTEN 状态。
客户端发送TCP连接请求客户端会随机一个初始序列号seq=x（client_isn），设置SYN=1 ，表示这是SYN握手报文。然后就可以把这个 SYN 报文发送给服务端了，表示向服务端发起连接，之后客户端处于同步已发送状态。
服务端发送针对TCP连接请求的确认服务端收到客户端的 SYN 报文后，也随机一个初始序列号（server_isn）(seq=y) 设置ack=x+1, 表示收到了客户端的x之前的数据，希望客户端下次发送的数据从x+1开始。设置 SYN=1 和 ACK=1。表示这是一个SYN握手和ACK确认应答报文。最后把该报文发给客户端，该报文也不包含应用层数据，之后服务端处于同步已接收状态。
客户端发送确认的确认客户端收到服务端报文后，还要向服务端回应最后一个应答报文，将ACK置为 1 ，表示这是一个应答报文 ack=y+1 ，表示收到了服务器的y之前的数据，希望服务器下次发送的数据从y+1开始。最后把报文发送给服务端，这次报文可以携带数据，之后客户端处于连接已建立状态。服务器收到客户端的应答报文后，也进入连接已建立状态

三次握手的好处：

防止历史连接在网络拥堵的情况下，客户端第一次握手的 SYN 包迟迟没能到达服务器，那么客户端会连续发送 SYN 建立连接的报文，就有可能出现后发的报文比早发的报文先到达服务器的情况。
- 两次握手时就不能判断当前连接是不是历史连接，导致错误发生
- 三次握手时，客户端可以根据自身上下文判断出这个报文是一个历史的连接，如果是则客户端发送 RST 报文给服务端，终止本次连接。
避免浪费资源如果只有「两次握手」，当客户端的 SYN 请求连接在网络中阻塞，客户端没有接收到 ACK 报文，就会重新发送 SYN 。
- 如果是三次握手，第三次握手时服务器可以得到客户端的ack，知道连接已成功建立。
- 如果没有第三次握手，服务器不清楚客户端是否收到了自己发送的建立连接的 ACK 确认信号，所以每收到一个 SYN 就只能先主动建立一个连接，如果客户端的 SYN 阻塞了，重复发送多次 SYN 报文，那么服务器在收到请求后就会建立多个冗余的无效链接，造成不必要的资源浪费。第三次握手带着 ACK 回去就代表着确认成功建立连接，可以进行数据发送。

TCP 四次挥手

流程如下：

主动方向对方发送一个 FIN 结束请求报文，并设置序列号和确认号，随后主动断开方进入FIN_WAIT1状态，这表示主动断开方已经没有业务数据要发给对方了，准备关闭连接了。
被动方收到FIN断开请求后会发送一个ACK响应报文，表明同意断开请求。随后被动断开方就进入CLOSE-WAIT状态（等待关闭状态），此时若被动断开方还有数据要发送给主动方，主动方还会接受。被动方会持续一段时间。主动方收到ACK报文后，由FIN_WAIT_1转换成FIN_WAIT_2状态。
被动断开方的CLOSE-WAIT（等待关闭）结束后，被动方会向主动方发送一个FIN+ACK报文，表示被动方的数据都发完了。然后被动方进入LAST_ACK状态。
主动断开方收到FIN+ACK断开响应报文后，还需进行最后确认，向被动方发送一个ACK确认报文，然后主动方进入TIME_WAIT状态，在等待完成2MSL时间后，如果期间没有收到被动方的报文，则证明对方已正常关闭，主动断开方的连接最终关闭。被动方在收到主动方第四次挥手发来的ACK报文后，就关闭了连接。

MSL 的值默认为 120s。

一些 QA：

为什么客户端在第四次挥手后还会等待2MSL 等待2MSL是因为保证服务端接收到了ACK报文，因为ACK报文可能会丢失，如果服务端没接收到ACK报文的话，会重新发送FIN报文，只有当客户端等待了2MSL都没有收到重新发送的FIN报文时，才表示服务端是正常接收到了ACK报文，这个时候客户端就能关闭了。

参考部分文章

TCP 三次握手：https://blog.csdn.net/qq_40337086/article/details/112443124
TCP 四次挥手：https://blog.csdn.net/Li6682438/article/details/124431638

无意义的定型文

“本手、妙手、俗手”是围棋的三个术语。本手是指合乎棋理的正规下法；妙手是指出人意料的精妙下法；俗手是指貌似合理，但从全局看通常会受损的下法。但即便是如此精通棋术的我，看到宇佐紀小姐时，我就好像迷失了方向，感觉我的棋盘发生了天翻地覆的变化，变得难以捉摸，无从下手。这一手棋…该怎么下，该如何下呢。当我用了一个通宵的时间来想是什么原因的时候，我看着我自己这身经百战的双手，又想起油批那迷人的微笑，终于想明白为什么了。在遇见宇佐紀小姐的那天，我便有了那怦然心动的感觉。

哪有什么“本手、妙手、俗手”？只有——“宇佐紀小姐，我想牵起你的手。”