网络协议系列文章

网络协议(一)：基本概念、计算机之间的连接方式

网络协议(二)：MAC地址、IP地址、子网掩码、子网和超网

网络协议(三)：路由器原理及数据包传输过程

网络协议(四)：网络分类、ISP、上网方式、公网私网、NAT

网络协议(五)：网络互联模型、物理层、数据链路层

网络协议(六)：网络层

网络协议(七)：传输层-UDP

网络协议(八)：传输层-TCP（三次握手、四次挥手原理）

一、TCP协议
二、可靠传输
- 1、停止等待ARQ协议
- 2、连续ARQ协议+滑动窗口协议
- 3、SACK（选择性确定）
三、拥塞控制
- 1、慢开始
- 2、拥塞避免
- 3、快重传
- 4、快恢复
四、序号、确认号（详细步骤）
五、建立连接（三次握手）
六、释放连接（四次挥手）

网络分层对应的通信协议和数据名称

在这里插入图片描述

一、TCP协议

TCP的几个要点

可靠传输
流量控制
拥塞控制
连接管理（建立连接、释放连接）

在这里插入图片描述

数据偏移

占4位，取值范围是 0b0101 ~ 0b1111（5~15）
乘以4：首部长度（Header Length）
首部长度是20~60字节

保留

占6位，目前全为0
有些资料中，TCP首部的保留(Reserved)字段占3位，标志(Flags) 字段占9位（Wireshark中也是如此）
因为标志位目前只用到了6位，所以可以说标识位空闲的3位和保留位3位合并为保留位6位

TCP的一个细节

UDP的首部中有个16位的字段记录了整个UDP报文段的长度（首部+数据）
但是，TCP的首部中仅仅有个4位的字段记录了TCP报文段的首部长度，并没有字段记录TCP报文段的数据长度

UDP首部中占16位的长度字段是冗余的，纯粹是为了保证首部是32bit对齐
TCP\UDP的数据长度，完全可以由IP数据包的首部推测出来
- 网络层首部记录着网络层的总长度
- 传输层的数据长度 = 网络层的总长度 – 网络层的首部长度 – 传输层的首部长度

检验和（CheckSum）

跟UDP一样，TCP检验和的计算内容：伪首部 + 首部 + 数据
伪首部：占用12字节，仅在计算检验和时起作用，并不会传递给网络层

标志位（Flags）

URG（Urgent）：当 URG = 1 时，紧急指针字段才有效。表明当前报文段中有紧急数据，应优先尽快传送
ACK（Acknowledgment）：当 ACK = 1 时，确认号字段才有效
PSH（Push）
RST（Reset）：当 RST = 1 时，表明连接中出现严重差错，必须释放连接，然后再重新建立连接
SYN（Synchronization）：当 SYN = 1、ACK = 0 时，表明这是一个建立连接的请求，若对方同意建立连接，则回复 SYN = 1、ACK = 1
FIN（Finish）：当 FIN = 1 时，表明数据已经发送完毕，要求释放连接

序号（Sequence Number）

占4字节
首先，在传输过程的每一个字节都会有一个编号
在建立连接后，序号代表：这一次传给对方的TCP数据部分的第一个字节的编号

确认号（Acknowledgment Number）

占4字节
在建立连接后，确认号代表：期望对方下一次传过来的TCP数据部分的第一个字节的编号

窗口（Window）

占2字节
这个字段有流量控制功能，用以告知对方下一次允许发送的数据大小（字节为单位）

二、可靠传输

可靠传输是为了保证包的完整性，当有丢包、受到三次重复确认等情况，就会重新发包

1、停止等待ARQ协议

ARQ（Automatic Repeat–reQuest），自动重传请求

在这里插入图片描述

疑问：重传次数？

若有个包重传了N次还是失败，会一直持续重传到成功为止么？
- 这个取决于系统的设置，比如有些系统，重传5次还未成功就会发送 reset报文(RST) 断开TCP连接

在这里插入图片描述

2、连续ARQ协议+滑动窗口协议

如果接收窗口最多能接收4个包，但发送方只发了2个包，接收方如何确定后面还有没有2个包？
- 等待一定时间后没有第3个包，就会返回确认收到2个包给发送方

在这里插入图片描述

A为发送端，B为接收端
滑动窗口相当于缓存的窗口
建立TCP连接时B告诉A接收窗口大小

在这里插入图片描述

3、SACK（选择性确定）

在TCP通信过程中，如果发送序列中间某个数据包丢失（比如1、2、3、4、5中3丢失了）
- TCP会通过重传最后确认的分组后续的分组（最后确认的是2，会重传3、4、5）
这样原先已经正确传输的分组也可能重复发送（比如4、5），降低了TCP性能
为改善上述情况，发展出了 SACK（Selective acknowledgment，选择性确认）技术
- 告诉发送方哪些数据丢失，哪些数据已经提前收到
- 使TCP只重新发送丢失的包（比如3），不用发送后续所有的分组（比如4、5）

SACK信息会放在TCP首部的选项部分

Kind：占1字节。值为5代表这是SACK选项
Length：占1字节。表明SACK选项一共占用多少字节
Left Edge：占4字节，左边界
Right Edge：占4字节，右边界

在这里插入图片描述

确认号201，期望对方发送201以后得数据段，但是把灰色部分数据段排除掉
一对边界信息需要占用8字节，由于TCP首部的选项部分最多40字节，所以
- SACK选项最多携带4组边界信息
- SACK选项的最大占用字节数 = 4 * 8 + 2 = 34

在这里插入图片描述

思考：为什么选择在传输层就将数据“大卸八块”分成多个段，而不是等到网络层再分片传递给数据链路层？

因为可以提高重传的性能
需要明确的是：可靠传输是在传输层进行控制的
- 如果在传输层不分段，一旦出现数据丢失，整个传输层的数据都得重传
- 如果在传输层分了段，一旦出现数据丢失，只需要重传丢失的那些段即可

三、拥塞控制

拥塞控制
- 防止过多的数据注入到网络中
- 避免网络中的路由器或链路过载
拥塞控制是一个全局性的过程
- 涉及到所有的主机、路由器
- 以及与降低网络传输性能有关的所有因素
- 是大家共同努力的结果
相比而言，流量控制是点对点通信的控制

在这里插入图片描述

拥塞控制方法

慢开始（slow start，慢启动）
拥塞避免（congestion avoidance）
快速重传（fast retransmit）
快速恢复（fast recovery）

几个概念

MSS（Maximum Segment Size）：每个段最大的数据部分大小（在建立连接时确定）
- 一般是 MTU(1500) - 20 - 20 = 1460
cwnd（congestion window）：拥塞窗口
rwnd（receive window）：接收窗口
swnd（send window）：发送窗口
- swnd = min(cwnd, rwnd) 发送窗口是拥塞窗口和接收窗口取最小的那个

1、慢开始

cwnd的初始值比较小，然后随着数据包被接收方确认（收到一个ACK）
cwnd就成倍增长（指数级）

在这里插入图片描述

2、拥塞避免

ssthresh (slow start threshold)：慢开始阈值，cwnd达到阈值后，开始拥塞避免（加法增大）
拥塞避免（加法增大）：拥塞窗口cwind 缓慢增大，以防止网络过早出现拥塞
乘法减小：只要出现网络拥塞，把ssthresh减为拥塞峰值的一半，同时执行慢开始算法（cwnd又恢复到初始值）
- 当网络出现频繁拥塞时，ssthresh值就下降的很快

在这里插入图片描述

3、快重传

接收方
- 每收到一个失序的分组后就立即发出重复确认
- 使发送方及时知道有分组没有到达
- 而不要等待自己发送数据时才进行确认
发送方
- 只要连续收到三个重复确认（总共4个相同的确认），就应当立即重传对方尚未收到的报文段
- 而不必继续等待重传计时器到期后再重传

在这里插入图片描述

4、快恢复

当发送方连续收到三个重复确认，说明网络出现拥塞
- 就执行“乘法减小”算法，把ssthresh减为拥塞峰值的一半
与慢开始不同之处是现在不执行慢开始算法，即cwnd现在不恢复到初始值
- 而是把cwnd值设置为新的ssthresh值（减小后的值）
- 然后开始执行拥塞避免算法（“加法增大”），使拥塞窗口缓慢地线性增大

在这里插入图片描述

四、序号、确认号（详细步骤）

左边紫色A客户端，右边蓝色B服务端
①②③：建立连接
④：发送http请求
⑤⑥⑦⑧：响应http请求
⑨：应答服务器

在这里插入图片描述

注意： s1是客户端的初始值（可以理解随机数）s2是服务端的初始值，这两边给对方发送数据的序号都是从初始值开始计算，所以也可以理解原生是s1和s2，相对则都是0

SYN ACK表示标记位是否为1，seq是序号，ack为确认号
①：客户端请求与服务器建立连接，syn=1表示客户端第一次发请求，也代表建立连接请求
- 数据部分占0字节，这里序号s1其实给服务端用的
- 第一次发，所以也没有应答ack=0，而且只有ACK = 1 时，确认号字段才有效
②：服务器应答客户端建立连接，syn=1表示服务器第一次发请求，也代表建立连接请求==
- 数据部分占0字节，这里序号s2也是给客户端用的
- 这里ack确认s1，期望收到s1+1的字节数据
③：应答②，因为②期望收到s1+1数据，那么③序号为s1+1，期望收到②s2+1数据，但是这里数据部分依然还是0字节
④：建立连接成功后，第一次请求数据，客户端从s1+1开始发数据，一共k字节，期望服务器从s2+1开始发

在这里插入图片描述

⑤：从④中期待的s2+1数据开始发送，其实也就是服务器的第一个字节数
- 期待客户端从s1+k+1发，因为④中请求发了k个字节
⑥⑦⑧：序号就是前一个数据的序号+发送的字节长度，ack都一样，都是上次http请求的s1+k+1

在这里插入图片描述

⑨：应答服务器发送的⑤⑥⑦⑧，序号则是⑤⑥⑦⑧期望的，但是这里数据占用0字节，其实只是应答，没有发数据了

在这里插入图片描述

相对：序号、确认号

在这里插入图片描述

原生：序号、确认号

在这里插入图片描述

五、建立连接（三次握手）

在这里插入图片描述

CLOSED：client处于关闭状态
LISTEN：server处于监听状态，等待client连接
SYN-SENT：表示client已发送SYN报文，等待server的第2次握手
SYN-RCVD：表示server接受到了SYN报文，当收到client的ACK报文后，它会进入到 ESTABLISHED 状态
ESTABLISHED：表示连接已经建立

前2次握手的特点

SYN 都设置为1
数据部分的长度都为0
TCP头部的长度一般是32字节
- 固定头部：20字节
- 选项部分：12字节
双方会交换确认一些信息
- 比如MSS、是否支持SACK、Window scale（窗口缩放系数）等
- 这些数据都放在了TCP头部的选项部分中（12字节）

为什么建立连接的时候，要进行3次握手？2次不行么？

主要目的：防止server端一直等待，浪费资源
如果建立连接只需要2次握手，可能会出现的情况：
- 假设client发出的第一个连接请求报文段，因为网络延迟，在连接释放以后的某个时间才到达server
- 本来这是一个早已失效的连接请求，但server收到此失效的请求后，误认为是client再次发出的一个新的连接请求
- 于是server就向client发出确认报文段，同意建立连接
- 如果不采用“3次握手”，那么只要server发出确认，新的连接就建立了
- 由于现在client并没有真正想连接服务器的意愿，因此不会理睬server的确认，也不会向server发送数据
- 但server却以为新的连接已经建立，并一直等待client发来数据，这样，server的很多资源就白白浪费掉了
采用 “三次握手” 的办法可以防止上述现象发生

如果第3次握手失败了，会怎么处理？

此时server的状态为 SYN-RCVD，若等不到client的 ACK，server会重新发送 SYN+ACK 包
如果server多次重发 SYN+ACK 都等不到client的 ACK，就会发送 RST包，强制关闭连接

六、释放连接（四次挥手）

FIN-WAIT-1：表示想主动关闭连接
- 向对方发送了FIN报文，此时进入到FIN-WAIT-1状态
CLOSE-WAIT：表示在等待关闭
- 当对方发送FIN给自己，自己会回应一个ACK报文给对方，此时则进入到CLOSE-WAIT状态
- 在此状态下，需要考虑自己是否还有数据要发送给对方，如果没有，发送FIN报文给对方
FIN-WAIT-2：只要对方发送ACK确认后，主动方就会处于FIN-WAIT-2状态，然后等待对方发送FIN报文
CLOSING：一种比较罕见的例外状态
- 表示你发送FIN报文后，并没有收到对方的ACK报文，反而却也收到了对方的FIN报文
- 如果双方几乎在同时准备关闭连接的话，那么就出现了双方同时发送FIN报文的情况，也即会出现CLOSING状态
- 表示双方都正在关闭连接
LAST-ACK：被动关闭一方在发送FIN报文后，最后等待对方的ACK报文
- 当收到ACK报文后，即可进入CLOSED状态了
TIME-WAIT：表示收到了对方的FIN报文，并发送出了ACK报文，就等 2MSL 后即可进入CLOSED状态了
- 如果FIN-WAIT-1状态下，收到了对方同时带FIN标志和ACK标志的报文时
- 可以直接进入到TIME-WAIT状态，而无须经过FIN-WAIT-2状态
CLOSED：关闭状态
- 由于有些状态的时间比较短暂，所以很难用 netstat 命令看到，比如SYN-RCVD、FIN-WAIT-1等

在这里插入图片描述

释放连接的一些细节

TCP/IP协议栈在设计上，允许任何一方先发起断开请求
client发送ACK后，需要有个TIME-WAIT阶段，等待一段时间后，再真正关闭连接
- 一般是等待2倍的 MSL（Maximum Segment Lifetime，最大分段生存期）
- MSL是TCP报文在Internet上的最长生存时间
- 每个具体的TCP实现都必须选择一个确定的MSL值，RFC 1122 建议是2分钟
- 可以防止发送ACK对方接收不到，会重新发送FIN，此时还需要应答
如果client发送ACK后马上释放了，然后又因为网络原因，server没有收到client的ACK，server就会重发FIN，这时可能出现的情况是
- ① client没有任何响应，服务器那边会干等，甚至多次重发FIN，浪费资源
- ② client有个新的应用程序刚好分配了同一个端口号，新的应用程序收到FIN后马上开始执行断开连接的操作，本来它可能是想跟server建立连接的