以下内容来自于小码哥"网络协议从入门到底层原理"
image.png
image.png
分析一下自己抓包的结果
image.png
上图是一个典型的三次握手
我们来分析一下第一次握手
-
第一次握手
image.png
第一次握手的数据部分的长度是0个字节, TCP首部占44个字节, 其中固定部分长度是20个字节, 选项部分长度是24个字节
TCP首部存储的是Sequence的raw值,而不是相对值 见下图
image.png
我们把这个值称为s1, 这个s1记录的是客户端->服务器发送的每一个segment的第一个字节的编号
-
我们来分析一下第二次握手
image.png
-
我们来分析一下第三次握手
image.png
三次握手后, TCP连接就成功建立
建立了发数据的通道, 这是一个全双工的通道, 即客户端也可以发给服务器, 服务器也可以发给客户端
-
然后客户端发给服务器
HTTP请求
image.png
-
服务端收到客户端发过来的
HTTP请求之后, 就会发给客户端一个收到的ACK响应
image.png
-
然后服务端就开始发数据给客户端了
image.png
看上图可以知道: 上图的ACK全部是719, 这是为什么呢? 719是ACK的相对值, 即718 + 1 = 719, 718是客户端发给服务器的HTTP请求的长度, 即TCP的数据部分, 所以ACK的raw值应该是期望客户端发给服务器的下一个包的第一个字节的值, 即s1 + b1 + 1, 因为在这个过程中, 并没有收到客户端发给服务器的任何数据包, 那么这个值就始终是s1 + b1 + 1, 相对值就始终是719.
但是会变化的是序号seq值, seq值是上一个包的seq值, 加上长度Len生成的, 比如上图中最后一个包的seq是4771, 而4771 = 4755 + 16, 4755就是上一个服务器发给客户端包的seq值. 如果把上图这7个包的长度分别记为k1, k2, k3, k4, k5, k6, k7的话, 那么最后一个包的seq相对值就是1 + k1 + k2 + k3 + k4 + k5 + k6, raw值就是s2 + 1 + k1 + k2 + k3 + k4 + k5 + k6,
让我们看看是不是这样, 我们点开最后一个包:
image.png
image.png
s2的值果然就是这样
- 接下来就是客户端对服务端的
ACK回应, 告诉客户端, 我收到包了:
image.png
注意看最后一个包的ACK是6223, 这就是服务器发给客户端的最后一个包的seq + Len:
image.png
- 就这样反反复复, 直到服务端这边已经发完了全部数据, 那么就会给客户端返回一个
200:
image.png
从上面的图可以看到, 客户端这边发的好多包的seq都为719, 这是因为客户端发的包都只是一个ACK回应, 表示: 哦, 我收到了, 这样的包的长度Len都为0, 所以seq都为s1 + b1 + 1, 就是相对值为719(718 + 1), raw值为2751725119(718 + 1 + s1(2751724400))
到此, 传输层的三次握手就分析完了.
TCP-建立连接-状态解读
-
CLOSED:client处于关闭状态 -
LISTEN:server处于监听状态, 等待client连接 -
SYN-RCVD: 表示server接受到了SYN报文, 当收到client的ACK报文后, 它会进入到ESTABLISHED状态 -
SYN-SENT:表示client已发送SYN报文, 等待server的第2次握手
image.png
TCP-建立连接-前2次握手的特点
-
SYN都设置为1 -
数据部分的长度都为
0 -
TCP头部的长度一般是32字节
-- 固定头部:20字节
-- 选项部分:12字节 -
双方会交换确认一些信息
-- 比如MSS, 是否支持SACK,Window scale(窗口缩放系数)等
TCP-建立连接-疑问
-
为什么建立连接的时候, 要进行
3次握手,2次不行吗?
-- 主要目的: 防止server端一直等待, 浪费资源 -
如果建立连接只需要
2次握手, 可能会出现的情况
-- 假设client发出的第一个连接请求报文段, 因为网络延迟, 在连接释放以后的某个时间才到达server
-- 本来这是一个早已失效的请求, 但server收到此失效的请求后, 误认为是client再次发出的一个新的连接请求
-- 于是server就向client发出确认报文段, 同意建立连接
-- 如果不采用"3次握手", 那么只要server发出确认, 新的连接就建立了
-- 由于现在client并没有真正想连接服务器的意愿, 因此不会理睬server的确认, 也不会向server发送数据
-- 但在server却以为新的连接已经建立, 并一直等待client发来数据, 这样,server的很多资源就白白浪费了 -
采用"三次握手"的办法可以防止上述现象发生
-- 例如上述情况,client没有向server的确认发出确认,server由于收不到确认, 就知道client并没有要求建立连接 -
第
3次握手失败了, 会怎么处理?
-- 此时server的状态为SYN-RCVD, 若等不到client的ACK,server会重新发送SYN+ACK包
-- 如果server多次重发SYN+ACK都等不到client的ACK, 就会发送RST包, 强制关闭连接
网友评论