三次握手四次挥手 3个月前

编程语言
741
三次握手四次挥手

TCP协议是一个安全的、面向连接的、流式传输协议，所谓的面向连接就是三次握手 对于我们来说只需要在客户端调用connect()函数，三次握手就自动进行了。 通过下图看TCP协议的格式

1. tcp协议介绍

image

在Tcp协议中，比较重要的字段有：

  • 源端口：表示发送端端口号，字段长 16 位，2个字节
  • 目的端口：表示接收端端口号，字段长 16 位，2个字节
  • 序号（sequence number）：字段长 32 位，占4个字节，序号的范围为 [0，4284967296]。
    • 由于TCP是面向字节流的，在一个TCP连接中传送的字节流中的每一个字节都按顺序编号
    • 首部中的序号字段则是指本报文段所发送的数据的第一个字节的序号，这是随机生成的。
    • 序号是循环使用的，当序号增加到最大值时，下一个序号就又回到了0
  • 确认序号（acknowledgement number）：占32位（4字节），表示收到的下一个报文段的第一个数据字节的序号，如果确认序号为N，序号为S，则表明到序号N-S为止的所有数据字节都已经被正确地接收到了。
  • 8个标志位（Flag）:
    • CWR：CWR 标志与后面的 ECE 标志都用于 IP 首部的 ECN 字段，ECE 标志为 1 时，则通知对方已将拥塞窗口缩小；
    • ECE：若其值为 1 则会通知对方，从对方到这边的网络有阻塞。在收到数据包的 IP 首部中 ECN 为 1 时将 TCP 首部中的 ECE 设为 1；
    • URG：该位设为 1，表示包中有需要紧急处理的数据，对于需要紧急处理的数据，与后面的紧急指针有关；
    • ACK：该位设为 1，确认应答的字段有效，TCP规定除了最初建立连接时的 SYN 包之外该位必须设为 1；
    • PSH：该位设为 1，表示需要将收到的数据立刻传给上层应用协议，若设为 0，则先将数据进行缓存；
    • RST：该位设为 1，表示 TCP 连接出现异常必须强制断开连接；
    • SYN：用于建立连接，该位设为 1，表示希望建立连接，并在其序列号的字段进行序列号初值设定；
    • FIN：该位设为 1，表示今后不再有数据发送，希望断开连接。
  • 窗口大小：该字段长 16 位，表示从确认序号所指位置开始能够接收的数据大小，TCP 不允许发送超过该窗口大小的数据。

2. 三次握手

Tcp连接是双向连接，客户端和服务器需要分别向对方发送连接请求，并且建立连接，三次握手成功之后，二者之间的双向连接也就成功建立了。如果要保证三次握手顺利完成，必须要满足以下条件：

  • 服务器端：已经启动，并且启动了监听（被动接受连接的一端）
  • 客户端：基于服务器端监听的IP和端口，向服务器端发起连接请求（主动发起连接的一端）

image

三次握手具体过程如下：

第一次握手：

  • 客户端：客户端向服务器端发起连接请求将报文中的SYN字段置为1，生成随机序号x，seq=x
  • 服务器端：接收客户端发送的请求数据，解析tcp协议，校验SYN标志位是否为1，并得到序号 x

第二次握手：

  • 服务器端：给客户端回复数据
    1. 回复ACK, 将tcp协议ACK对应的标志位设置为1，表示同意了客户端建立连接的请求
    2. 回复了 ack=x+1, 这是确认序号
      • x: 客户端生成的随机序号
      • 1: 客户端给服务器发送的数据的量, SYN标志位存储到某一个字节中, 因此按照一个字节计算，表示客户端给服务器发送的1个字节服务器收到了。
    3. 将tcp协议中的SYN对应的标志位设置为 1, 服务器向客户端发起了连接请求
    4. 服务器端生成了一个随机序号 y, 发送给了客户端
  • 客户端：接收回复的数据，并解析tcp协议
    1. 校验ACK标志位，为1表示服务器接收了客户端的连接请求
    2. 数据校验，确认发送给服务器的数据服务器收到了没有，计算公式如下： 发送的数据的量 = 使用服务器回复的确认序号 - 客户端生成的随机序号 ===> 1=x+1-x
    3. 校验SYN标志位，为1表示服务器请求和客户端建立连接
    4. 得到服务器生成的随机序号: y

第三次握手：

  • 客户端：发送数据给服务器
    1. 将tcp协议中ACK标志位设置为1，表示同意了服务器的连接请求
    2. 给服务器回复了一个确认序号 ack = y+1
      • y：服务器端生成的随机序号
      • 1：服务器给客户端发送的数据量，服务器给客户端发送了ACK和SYN, 都存储在这一个字节中
    3. 发送给服务器的序号就是上一次从服务器端收的确认序号因此 seq = x+1
  • 服务器端：接收数据, 并解析tcp协议
    1. 查看ACK对应的标志位是否为1, 如果是1代表, 客户端同意了服务器的连接请求
    2. 数据校验，确认发送给客户端的数据客户端收到了没有，计算公式如下： 给客户端发送的数据量 = 确认序号 - 服务器生成的随机序号 ===> 1=y+1-y
    3. 得到客户端发送的序号：x+1

3. TCP四次挥手

四次挥手是断开连接的过程，需要双向断开，关于由哪一端先断开连接是没有要求的。通信的两端如果想要断开连接就需要调用close()函数，当两端都调用了该函数，四次挥手也就完成了。

  • 客户端和服务器断开连接 -> 单向断开
  • 服务器和客户端断开连接 -> 单向断开

进行了两次单向断开，双向断开就完成了，每进行一次单向断开，就会完成两次挥手的动作。

image

基于上图的例子对四次挥手的具体过程进行阐述（实际上那端先断开连接都是允许的）：

第一次挥手:

  • 主动断开连接的一方：发送断开连接的请求
    1. 将tcp协议中FIN标志位设置为1，表示请求断开连接
    2. 发送序号x给对端，seq=x，基于这个序号用于客户端数据校验的计算
  • 被动断开连接的一方：接收请求数据, 并解析TCP协议
    1. 校验FIN标志位是否为1
    2. 收到了序号 x，基于这个数据计算回复的确认序号 ack 的值

第二次挥手:

  • 被动断开连接的一方：回复数据
    1. 同意了对方断开连接的请求，将ACK标志位设置为1
    2. 回复 ack=x+1，表示成功接受了客户端发送的一个字节数据
    3. 向客户端发送序号 seq=y，基于这个序号用于服务器端数据校验的计算
  • 主动断开连接的一方：接收回复数据, 并解析TCP协议
    1. 校验ACK标志位，如果为1表示断开连接的请求对方已经同意了
    2. 校验 ack确认发送的数据服务器是否收到了，发送的数据 = ack - x = x + 1 -x = 1

第三次挥手:

  • 被动断开连接的一方：将tcp协议中FIN标志位设置为1，表示请求断开连接
  • 主动断开连接的一方：接收请求数据, 并解析TCP协议，校验FIN标志位是否为1

第四次挥手:

  • 主动断开连接的一方：回复数据
    1. 将tcp协议中ACK对应的标志位设置为1，表示同意了断开连接的请求
    2. ack=y+1，表示服务器发送给客户端的一个字节客户端接收到了
    3. 序号 seq=h，此时的h应该等于 x+1，也就是第三次挥手时服务器回复的确认序号ack的值
  • 被动断开连接的一方：收到回复的ACK, 此时双向连接双向断开, 通信的两端没有任何关系了

4. 流量控制

流量控制可以让发送端根据接收端的实际接受能力控制发送的数据量。 它的具体操作是，接收端主机向发送端主机通知自己可以接收数据的大小，于是发送端会发送不会超过该大小的数据，该限制大小即为窗口大小，即窗口大小由接收端主机决定。

TCP 首部中，专门有一个字段来通知窗口大小，接收主机将自己可以接收的缓冲区大小放在该字段中通知发送端。 当接收端的缓冲区面临数据溢出时，窗口大小的值也是随之改变，设置为一个更小的值通知发送端，从而控制数据的发送量，这样达到流量的控制。这个控制流程的窗口也可以称作滑动窗口。

此图为一个单向的数据发送:

image

左侧是数据发送端：对应的是发送端的写缓冲区(内存)，通过一个环形队列进行数据管理

  • 白色格子: 空闲的内存, 可以写数据
  • 粉色的格子: 被写入到内存, 但是还没有被发送出去的数据
  • 灰色的格子: 代表已经被发送出去的数据

右侧是数据接收端：对应的是接收端的读缓冲区，存储发送端发送过来的数据

  • 白色格子：空闲的内存, 可以继续接收数据, 滑动窗口的值记录的就是白色的格子的大小
    • 随着接收的数据越来越多, 白色格子越来越少, 滑动窗口的值越来越小
    • 如果白色格子没有了, 滑动窗口变为0, 这时候, 发送端就被阻塞了
  • 粉色格子：接收的数据，但是这个数据还没有从内核中读走，使用read() / recv()
    • 粉色格子变少了, 可用空间就变多了, 滑动窗口的值就变大了
    • 如果滑动窗口的值从0变为大于0, 接收端又重新有容量接收数据了, 发送端的阻塞自动解除，继续发送数据

基于TCP通信的流程图，记录了从三次握手 -> 数据通信 -> 四次挥手的全过程：

image



# fast sender: 客户端
# slow recerver: 服务器
# win: 滑动窗口大小
# mss: maximum segment size, 单条数据的最大长度

第1步：第一次握手，发送连接请求SYN到服务器端

  • 0(0)：0表示客户端生成的随机序号，(0)表示客户端没有额外给服务器发送数据, 因此数据的量为0
  • win4096: 客户端告诉服务器, 能接收的数据(缓存)的最大量为4k
  • mss1460: 客户端可以处理的单条最大字节数是1460字节

第2步：第二次握手

  • ACK: 服务器同意了客户端的连接请求
    • SYN: 服务器请求和客户端建立连接
  • 8000(0)：8000是服务器端生成的随机序号，(0)表示服务器没有额外给客户端发送数据, 因此数据的量为0
  • 1: 发送给客户端的确认序号
    • 确认序号 = 客户端生成的随机序号 + 客户端给服务器发送的数据量(字节数) ===> 1=0+1
    • 表示客户端给服务器发送的1个字节服务器收到了
  • win6144: 服务器告诉客户端我能最多缓存 6k数据
  • mss1024: 服务器能处理的单条数据最大长度是 1k

第3步: 第三次握手

  • ACK: 客户端同意了服务器的连接请求
  • 8001: 发送给服务器的确认序号
    • 确认序号 = 服务器生成的随机序号 + 服务器给客户端发送的数据量 ===> 8001 = 8000 + 1
    • 客户端告诉服务器, 你给我发送的1个字节的数据我收到了
  • win4096: 告诉服务器客户端能缓存的最大数据量是4k

第4~9步: 客户端给服务器发送数据

  • 1(1024)：1 （1-0）表示之前一共给服务器发送了1个字节，(1024)表示这次要发送的数据量为 1k
  • 1025(1024)：1025（1025-0）表示之前一共给服务器发送了1025个字节，(1024)表示这次要发送的数据量为 1k
  • 2049(1024)：2049（2049-0）表示之前一共给服务器发送了2049个字节，(1024)表示这次要发送的数据量为 1k
  • 第9步完成之后，服务器的滑动窗口变为0，接收数据的缓存被写满了，发送端阻塞

第10步:

  • ack6145: 服务器给客户端回复数据，6145是确认序号, 代表实际接收的字节数 服务器实际接收的字节数 = 确认序号 - 客户端生成的随机序号 ===> 6145 = 6145 - 0
  • win2048：服务器告诉客户端我的缓存还有2k，也就是还有4k还在缓存中没有被读走

第11步：win4096表示滑动窗口变为4k，代表还可以接收4k数据，还有2k在缓存中

第12步：客户端又给服务器发送了1k数据

第13步: 第一次挥手，FIN表示客户端主动和服务器断开连接，并且发送了1k数据到服务器端

第14步: 第二次挥手，回复ACK, 同意断开连接

第15, 16步: 服务器端从读缓冲区中读数据, 第16步数据读完, 滑动窗口变成最大的6k

第17步: 第三次挥手

  • FIN: 服务器请求和客户端断开连接
  • 8001(0): 服务器一共给客户端发送的字节数 8001 - 8000 = 1个字节，携带的数据量为0（FIN不计算在内）
  • ack8194: 服务器收到了客户端的多少个字节: 8194 - 0 = 8194个字节

第18步: 第四次挥手

  • ACK: 客户端同意了服务器断开连接的请求
  • 8002: 确认序号, 可以计算出服务器给客户端发送了多少数据，8002 - 8000 = 2 个字节
image
EchoEcho官方
无论前方如何，请不要后悔与我相遇。
1377
发布数
439
关注者
2223697
累计阅读

热门教程文档

Lua
21小节
10.x
88小节
Objective-C
29小节
PHP
52小节
Vue
25小节
0 1