面试-三次握手和四次挥手目录
- TCP/IP报文格式
- 三次握手
- 四次挥手
- 为什么握手一定要三次?
- 为什么挥手一定要四次?
TCP/IP报文格式
只针对本节需要讲解的内容, 对报文格式内容进行简单提取:
- 序列号（Sequence Number）
+ 该字段用来标识TCP源端设备向目的端设备发送的字节流，它表示在这个报文段中的第几个数据字节。序列号是一个32位的数。 - 确认号（Acknowledge Number）
+ TCP使用32位的确认号字段标识期望收到的下一个段的第一个字节，并声明此前的所有数据已经正确无误地收到，因此，确认号应该是上次已成功收到的数据字节序列号加1。收到确认号的源计算机会知道特定的段已经被收到。确认号的字段只在ACK标志被设置时才有效。 - ACK：表示响应 , 确认标志位;
+ 确认字符 ACK (ACKnowledge Character）
+ 取1时表示应答字段有效，也即TCP应答号将包含在TCP段中，为0则反之。 - SYN：表示建立连接, 同步序列编号，该标志仅在三次握手建立TCP连接时有效.
+ 同步序列编号 SYN（Synchronize Sequence Numbers）
+ 取1时表示请求建立连接 - FIN: 表示关闭连接
+ finish 结束标志
三次握手
- 为了建立可靠的连接
- 第一次握手: 客户端会先向服务器端发送一个报文, 报文的 SYN位 的标志位是 置1 的, 并且携带32位的随机序列号(seq = j) ;
- 第二次握手: 服务器收到了客户端发送的 SYN 包后, 就会知道客户端要跟我发起一次新的连接, 此时会给客户端发送2个报文,
一个是 ACK 确认消息包, 消息包里面 ACK位-置1,它的序号是 j+1 (ack = j+1),
另一个服务器自己的 SYN 包(SYN位的标志位是1), 并且也会携带32位的随机序列号(seq = k), - 第二次握手后, 客户端就已经进入成功连接的状态了(既能给服务器发消息, 也能收到服务器的消息),
但是服务器端还没进入成功连接的状态(服务器不知道发给客户端的消息, 客户端能不能收到), 因此需要第三次握手. - 第三次握手: 客户端收到了服务器发的 ACK 包和 SYN 包后, 会像服务器发送一个 ACK 确认包(ACK位-置1), 它的序号是 ack = k+1 ;
客户端发送完确认包以后, 客户端和服务器就会进入一个完成连接的状态, 客户端和服务器就可以传输数据了
四次挥手
- 由于tcp/ip连接全双工的, 因此在断开的时候, 需要客户端和服务器端每一方都单独进行关闭.
- 全双工: 在同一个时刻, 客户端和服务端, 可以同时向对方发送数据
- 第一次挥手, 客户端发送一个 FIN报文, FIN位会置1, 用来关闭客户端到服务器端的数据传送, FIN( seq = j ) ;
- 第二次挥手, 服务器端收到 FIN 包后, 就会知道客户端想要和我断开连接, 但是此时, 服务器端不一定可以做好准备, 这个时候, 服务器 端有可能还有没发送完的消息需要发送,
所以只能先进行断开请求的消息确认, 会先给客户端发回一个 ACK 确认包, 序号是收到的 FIN 包的序号+1, ACK( ack = j+1 ); - 第三次挥手, 服务器会给客户端发送一个 FIN 报文给客户端, FIN( seq = k ), 这个报文表示服务器端已经做好了关闭到客户端连接的准备;
- 第四次挥手, 客户端收到服务器发来的 FIN 包后, 同样会给服务器发送一个 ACK 确认包,序号也是在FIN的包的序号上加1的 ack( k+1 ).
为什么握手一定要三次?
- 为了实现可靠数据传输， TCP 协议的通信双方， 都必须维护一个序列号， 以标识发送出去的数据包中， 哪些是已经被对方收到的。 三次握手的过程即是通信双方相互告知序列号起始值， 并确认对方已经收到了序列号起始值的必经步骤。
- 如果只是两次握手， 至多只有连接发起方的起始序列号能被确认， 另一方选择的序列号则得不到确认。
为什么挥手一定要四次?
在连接关闭的时候, 服务器端收到了 FIN 报文之后, 此时, 服务器端有可能还有没发送完的消息需要发送, 不会立即关闭 , 所以只能先回复一个 ack 确认报文, 告诉客户端, 收到了你发送的 FIN 包, 但是我这不边不能立刻关闭, 我需要等所有的报文都发送完了, 准备好断开了, 才能再发送 FIN 报文来进行关闭.
