TCP三次握手和四次挥手

最新推荐文章于 2024-04-27 09:30:49 发布

三师兄东流

最新推荐文章于 2024-04-27 09:30:49 发布

阅读量190

点赞数

分类专栏： # http/https 文章标签： http 三次握手四次挥手 tcp

本文链接：https://blog.csdn.net/qq_25283709/article/details/102531836

版权

http/https 专栏收录该内容

1 篇文章 0 订阅

订阅专栏

概要

http三次握手和四次挥手图文笔记。

图例

在这里插入图片描述

涉及名词解释
- seq：序列号，占4个字节，用来标记数据段的顺序，发送的所有数据字节都被编上一个序号。
  - SYN消耗一个序号
  - FIN消耗一个序号
  - 初始值：初始序INS号（Initial Sequence Number）+1,因为SYN标志消耗了一个序号
- ack：确认号，占4个字节，确认序号包含发送确认的一端所期望收到的下一个序号。因此，确认序号应当是上次已成功收到数据字节序号加 1
- ACK：占1位，只有A C K标志为 1时确认序号字段才有效。
- SYN：同步序列编号（Synchronize Sequence Numbers），连接建立时用于同步序号。当SYN=1，ACK=0时表示：这是一个连接请求报文段。若同意连接，则在响应报文段中使得SYN=1，ACK=1。因此，SYN=1表示这是一个连接请求，或连接接受报文。SYN这个标志位只有在TCP建产连接时才会被置1，握手完成后SYN标志位被置0。
- FIN：终止标记，发送方完成数据发送。
- MSL：(Maximum Segment Lifetime)报文最长存活时间。
  - 每个具体 T C P实现必须选择一个报文段最大生存时间M S L（Maximum Segment Lifetime）。它是任何报文段被丢弃前在网络内的最长时间。我们知道这个时间是有限的，因为 T C P报文段以I P数据报在网络内传输，而I P数据报则有限制其生存时间的T T L字段。
  - RFC 793 [Postel 1981c] 指出MSL为2分钟。然而，实现中的常用值是30秒，1分钟，或2分钟。

三次握手

第一次握手，Client端发送一个SYN（seq=x）包，指明要连接的服务器端口，请求建立连接，并进入SYN_SENT状态。
第二次握手，Server端收到SYN包，进行确认包发送ACK（ack=x+1），并发送自己的SYN(seq=y+1)包，之后进入SYN_RECV状态。
第三次握手，Client端收到Server端发送的SYN+ACK包，确认ACK=1且ack=x+1，则向服务器发送确认包ACK（ack=y+1），此时序列号seq=x+1，确认包送完毕，Client端和Server端均进入ESTABLISHED（TCP连接成功）状态，完成三次握手。

四次挥手

建立一个连接需要三次握手，而终止一个连接要经过 4次握手。这由T C P的半关闭（h a l f -
c l o s e）造成的。既然一个T C P连接是全双工（即数据在两个方向上能同时传递），因此每个方
向必须单独地进行关闭。这原则就是当一方完成它的数据发送任务后就能发送一个 F I N来终止
这个方向连接。当一端收到一个 F I N，它必须通知应用层另一端几经终止了那个方向的数据传
送。发

第一次挥手，Client端发送数据完成，发送FIN包，FIN=1，seq=p(中间数据传输最后一个序列号+1),发送完毕，进入FIN_WAIT_1（终止等待1）状态。
第二次挥手
- Server端收到FIN包，发出确认包，ACK=1，seq=j,ack=p+1，并且带上自己的序列号seq=j，发送完毕，进入CLOSE_WAIT（关闭等待）状态；
- Client端收到ACK确保包,进入FIN_WAIT_2（终止等待2）状态，等待Server端发送完毕数据之后，发送FIN包。
- 这时候处于半关闭状态，即此时Client端已不会再向Server端发送数据，但是如果Server端有数据未发送完成，Client端依然可以接收Server端的数据。
第三次挥手，Server端所有数据发送完毕，发送FIN包,FIN=1,seq=k(k>j,在Server端收到FIN包，进入关闭等待状态之后可能发送了若干数据，序列号增加)，进入LAST_ACK（最后确认状态）。
第四次挥手
- Client端收到FIN包，发送确认包，ACK=1,seq=p+1,ack=k+1,进入TIME-WAIT（时间等待）状态。
- Server端收到ACK确认包，立即进入CLOSED（关闭）状态，TCP连接结束。
- Client端在等待2*MSL时间之后，进入CLOSEED（关闭状态），TCP连接结束。

FAQ

TCP三次握手的第三次的 ack包丢失会怎样？
- Server
  - 第三次的ACK在网络中丢失，那么Server 端该TCP连接的状态为SYN_RECV,并且会根据 TCP的超时重传机制，会等待3秒、6秒、12秒后重新发送SYN+ACK包，以便Client重新发送ACK包。
  - Server重发SYN+ACK包的次数，可以通过设置/proc/sys/net/ipv4/tcp_synack_retries修改，默认值为5.
  - 如果重发指定次数之后，仍然未收到 client 的ACK应答，那么一段时间后，Server自动关闭这个连接。
- Client
  - 第三次握手中的ACK包丢失的情况下，Client 向 server端发送数据，Server端将以 RST包响应，方能感知到Server的错误。
为什么连接的时候是三次握手，关闭的时候却是四次握手？
- 因为当Server端收到Client端的SYN连接请求报文后，可以直接发送SYN+ACK报文。其中ACK报文是用来应答的，SYN报文是用来同步的。但是关闭连接时，当Server端收到FIN报文时，很可能并不会立即关闭SOCKET，所以只能先回复一个ACK报文，告诉Client端，“你发的FIN报文我收到了”。只有等到我Server端所有的报文都发送完了，我才能发送FIN报文，因此不能一起发送。故需要四步握手。
为什么TIME_WAIT状态需要经过2MSL(最大报文段生存时间)才能返回到CLOSE状态？
- 虽然按道理，四个报文都发送完毕，我们可以直接进入CLOSE状态了，但是我们必须假象网络是不可靠的，有可以最后一个ACK丢失。所以TIME_WAIT状态就是用来重发可能丢失的ACK报文。在Client发送出最后的ACK回复，但该ACK可能丢失。Server如果没有收到ACK，将不断重复发送FIN片段。所以Client不能立即关闭，它必须确认Server接收到了该ACK。Client会在发送出ACK之后进入到TIME_WAIT状态。Client会设置一个计时器，等待2MSL的时间。如果在该时间内再次收到FIN，那么Client会重发ACK并再次等待2MSL。所谓的2MSL是两倍的MSL(Maximum Segment Lifetime)。MSL指一个片段在网络中最大的存活时间，2MSL就是一个发送和一个回复所需的最大时间。如果直到2MSL，Client都没有再次收到FIN，那么Client推断ACK已经被成功接收，则结束TCP连接。
为什么不能用两次握手进行连接？
- 3次握手完成两个重要的功能，既要双方做好发送数据的准备工作(双方都知道彼此已准备好)，也要允许双方就初始序列号进行协商，这个序列号在握手过程中被发送和确认。
- 现在把三次握手改成仅需要两次握手，死锁是可能发生的。作为例子，考虑计算机S和C之间的通信，假定C给S发送一个连接请求分组，S收到了这个分组，并发送了确认应答分组。按照两次握手的协定，S认为连接已经成功地建立了，可以开始发送数据分组。可是，C在S的应答分组在传输中被丢失的情况下，将不知道S 是否已准备好，不知道S建立什么样的序列号，C甚至怀疑S是否收到自己的连接请求分组。在这种情况下，C认为连接还未建立成功，将忽略S发来的任何数据分组，只等待连接确认应答分组。而S在发出的分组超时后，重复发送同样的分组。这样就形成了死锁。
如果已经建立了连接，但是客户端突然出现故障了怎么办？
- TCP还设有一个保活计时器，显然，客户端如果出现故障，服务器不能一直等下去，白白浪费资源。服务器每收到一次客户端的请求后都会重新复位这个计时器，时间通常是设置为2小时，若两小时还没有收到客户端的任何数据，服务器就会发送一个探测报文段，以后每隔75秒钟发送一次。若一连发送10个探测报文仍然没反应，服务器就认为客户端出了故障，接着就关闭连接。