TCP/IP基础1:TCP连接管理

0 TCP头

TCP/IP基础1:TCP连接管理
TCP头不加Option占用20个字节(32×5 bit)。
Sequence Number表示自己发出去的***。
Ack Num表示对别人***的回复。

1 TCP连接管理

1.1 TCP的连接建立与终止

TCP/IP基础1:TCP连接管理
使用Wireshark抓包,三次握手图片如下图所示。TCP的头部的8位bit可以多个使用。
TCP/IP基础1:TCP连接管理
TCP/IP基础1:TCP连接管理
TCP/IP基础1:TCP连接管理

Q:为什么TCP要三次握手四次挥手?

1、三次握手
TCP握手时,完成的是对***的交换。
1次握手,那么发送方不会知道是否握手成功,也没有交换到***。所以不可以。
2次握手,发送方发送syn+seq,接受方回复syn+seq+ack。此时接受方并不知道发送方没有收到ack。并不能保证数据传输的可靠
4次握手,发送方和接收方分别发送
syn+seq,
ack,
syn+seq,
ack
但是其中接受方的ack和syn可以合并到一起,这样就可以保证传输效率
https://www.zhihu.com/question/24853633/answer/115173386
2、四次挥手
四次挥手时,可以将接收方的ack+fin合并到一起啊,为什么这里不合起来发呢?
因为TCP连接是双向传输的对等的模式,就是说双方都可以同时向对方发送或接收数据。当有一方要关闭连接时,会发送指令告知对方,我要关闭连接了。这时对方会回一个ACK,此时一个方向的连接关闭。但是另一个方向仍然可以继续传输数据,等到发送完了所有的数据后,会发送一个FIN段来关闭此方向上的连接。接收方发送ACK确认关闭连接。注意,接收到FIN报文的一方只能回复一个ACK, 它是无法马上返回对方一个FIN报文段的,因为结束数据传输的“指令”是上层应用层给出的。
一句话来说就是由于TCP双向传输数据,一方结束时,另一方有可能还要发送数据,所以此处不能直接发送ack+fin来把另一个方向也关闭掉。

1.2 TCP状态转换

TCP/IP基础1:TCP连接管理

其中分为开启、数据传输、关闭三个部分。

开启分为主动开启、被动开启和同时开启。由CLOSED 进入LISTEN状态为被动开始,进入SYN_SENT为主动开启。

数据传输为ESTABLISHED状态。

关闭分为主动关闭、被动关闭和同时关闭。

1.2.1 TIME_WAIT状态(2MSL) 目的

TIME_WAIT状态的存在有两个理由:(1)让4次握手关闭流程更加可靠;4次握手的最后一个ACK是是由主动关闭方发送出去的,若这个ACK丢失,被动关闭方会再次发一个FIN过来。若主动关闭方能够保持一个2MSL的TIME_WAIT状态,则有更大的机会让丢失的ACK被再次发送出去。(2)防止lost duplicate对后续新建正常链接的传输造成破坏。
lost duplicate在实际的网络中非常常见,经常是由于路由器产生故障,路径无法收敛,导致一个packet在路由器A,B,C之间做类似死循环的跳转。IP头部有个TTL,限制了一个包在网络中的最大跳数,因此这个包有两种命运,要么最后TTL变为0,在网络中消失;要么TTL在变为0之前路由器路径收敛,它凭借剩余的TTL跳数终于到达目的地。但非常可惜的是TCP通过超时重传机制在早些时候发送了一个跟它一模一样的包,并先于它达到了目的地,因此它的命运也就注定被TCP协议栈抛弃。另外一个概念叫做incarnation connection,指跟上次的socket pair一摸一样的新连接,叫做incarnation of previous connection。lost duplicate加上incarnation connection,则会对我们的传输造成致命的错误。大家都知道TCP是流式的,所有包到达的顺序是不一致的,依靠***由TCP协议栈做顺序的拼接;假设一个incarnation connection这时收到的seq=1000, 来了一个lost duplicate为seq=1000, len=1000, 则tcp认为这个lost duplicate合法,并存放入了receive buffer,导致传输出现错误。通过一个2MSL TIME_WAIT状态,确保所有的lost duplicate都会消失掉,避免对新连接造成错误。

相关文章:

  • 2022-12-23
  • 2021-07-03
  • 2021-05-04
  • 2022-01-16
  • 2021-04-30
  • 2021-07-22
猜你喜欢
  • 2021-10-11
  • 2022-12-23
  • 2021-05-24
  • 2022-03-02
  • 2022-01-07
  • 2021-10-04
相关资源
相似解决方案