TCP三次握手和四次挥手

TCP协议定义

传输控制协议(TCP,Transmission Control Protocol)是一种面向连接的、可靠的、基于字节流的传输层通信协议,由IETF的RFC 793 定义。

网络模型

网络协议.png

TCP/IP.jpg

TCP数据格式

TCP数据格式.jpeg
TCP分组格式图.jpeg
  • 序列号
    SYN未置位:标识用户数据去中xx个字节的序号
    SYN置位: 标识初始发送的序列号
  • 确认号
    ACK置位:表示接收到的一个报文段的序号+1,即目的主机希望下次接收到报文段的序号值,序列号=前一个seq+报文段len。
  • 控制位
    URG:URG=1 --> 紧急指针字段有效
    ACK: ACK=1 --> 确认号字段有效,TCP规定在连接建立后所有传达的报文段ACK都须置为1
    PSH:PUSH- 推送,数据交互
    RST: 复位TCP连接
    SYN:三次握手建立TCP连接有效。SYN=1,ACK=0 表示这是一个连接请求报文段,若对方同意建立连接,则相应报文段使用SYN=1,ACK=1
    FIN: 用来释放一个TCP连接 。FIN=1,表明此报文端发送方数据已经发送完毕,要求释放连接。

三次握手

用途

建立TCP连接

握手作用

确认双方的接收和发送能是是否正常,初始序列号,交换窗口大小以及MSS等信息

示意图

三次握手.png
  1. 客户端发送SYN报文,请求建立连接,进入SYN_SENT状态,等到服务器确认
  2. 服务端收到SYN报文,发送ACK确认报文给客户端,同时发送SYN报文,即SYN+ACK,服务器进入SYN_RCVD状态
  3. 客户端收到SYN+ACK报文,发送ACK包给服务端,客户端进入ESTABLISHED状态。服务器收到客户端发送的ACK包之后也进入ESTABLISHED状态,三次握手完成
三次握手示例.png
  1. 第一次、第二次握手不可以携带数据,而第三次握手是可以携带数据的。
  2. 起始包的seq都等于0
  3. 三次握手中的ack=对方上一个的seq+1
  4. seq等于对方上次的ack号

为啥要三次握手

1. 确认双方接收数据和发送数据的能力。
2. 序列号可靠同步。
如果是两次握手,服务端无法确定客户端是否已经接收到了自己发送的初始序列号,如果第二次握手报文丢失,那么客户端就无法知道服务端的初始序列号(ISN,动态随机),那 TCP 的可靠性就无从谈起。
3. 阻止重复历史连接的初始化。

  • 客户端由于某种原因发送了两个不同序号的 SYN 包,我们知道网络环境是复杂的,旧的数据包有可能先到达服务器。如果是两次握手,服务器收到旧的SYN 就会立刻建立连接,那么会造成网络异常。
  • 如果是三次握手,服务器需要回复 SYN+ACK 包,客户端会对比应答的序号,如果发现是旧的报文,就会给服务器发 RST 报文,直到正常的 SYN到达服务器后才正常建立连接。
  • 客户端和服务器端能够及时地察觉到因为网络等一些问题导致的连接创建失败,这样服务器端的端口就可以关闭了不用一直等待。

4. 安全问题。
TCP 新建连接时,内核会为连接分配一系列的内存资源,如果采用两次握手,就建立连接,那会放大 DDOS 攻击的。

四次挥手

四次挥手.png
  1. \color{#84CB78}{客户端}发起\color{#84CB78}{FIN}包,客户端进入\color{#84CB78}{FIN\_WAIT\_1}状态。TCP规定,即使FIN不携带数据包也消耗一个序号。
  2. \color{#ED7E08}{服务端}收到FIN包,发出确认包\color{#ED7E08}{ACK},并带上自己的序号seq=v,服务端进入\color{#ED7E08}{CLOSE\_WAIT}状态。此时,客户端不再发送数据,但还可以接收服务端发送的数据(如果服务端有数据发送)。\color{#84CB78}{客户端}接收到服务端发送的ACK后,进入\color{#84CB78}{FIN\_WAIT\_2}
    3.\color{#ED7E08}{服务端}发送完数据后,向客户端发送\color{#ED7E08}{FIN}包, 半连接状态下服务器可能有发送了一些数据(假设seq为w)。此时服务器进入\color{#ED7E08}{LAST\_CHECK}状态
  3. \color{#84CB78}{客户端}收到服务起发送的FIN包后,发出ACK确认包,此时客户端进入\color{#84CB78}{TIME\_WAIT}。此时TCP连接还没释放,必须经过\color{#84CB78}{2*MSL}后,进入\color{#84CB78}{CLOSED}状态。而服务端收到客户端发送的确认包后就进入了CLOSED状态,服务端结束TCP连接的事件要比客户端早一些。
四次挥手.png
  1. TCP除了主动发起连接的第一个SYN包,ACK=0,其它所有TCP包都设置ACK= 1 标志位。
  2. 接到对方数据,如果没有数据要发送,需要用一个ACK确认对方,如果ACK丢,不会为ACK重传。
  3. 如果有数据要发送,顺便捎带ACK,确认对方的数据,如果数据丢,会重传数据。
三次挥手.png

在实际应用中由于延迟确认(也就是确认报文由下一个发送报文携带,一起传送过来),第二次挥手ACK与第三次挥手FIN合并成了一次。

为啥要四次握手

  1. 主动关闭方发送 FIN 包后,接收端可能还要发送数据,不能立即关闭服务器端到客户端的数据通道,所以也就不能将服务器端的 FIN 包与对客户端的 ACK 包合并发送,只能先确认ACK,然后服务器待无需发送数据时再发送 FIN 包,所以四次挥手时必须是四次数据包的交互。
  2. 服务端端收到FIN请求后要先应答ACK。
  3. 等发完未发的数据,然后再发FIN。

常见问题

1. 什么是半连接

  • 服务器第一次收到客户端的 SYN 之后,就会处于 SYN_RCVD 状态,此时双方还没有完全建立连接。服务器会把这种状态下请求连接放在一个队列里,我们把这种队列称之为半连接队列。
  • 一直没收到第三次握手,服务端发重传包,达到规定次数,从半连接队列里删除。(发重传包间隔时间一般指数增长)
  • 全连接队列,就是已经完成三次握手,建立起连接的就会放在全连接队列中。如果队列满了就有可能会出现丢包现象。

3. 为啥要等2MSL

MSL:maximum segment lifetime——最大报文生命周期,报文在网络上存在的最长时间,超过这个时间报文将被丢弃。

  1. 网络中可能存在发送方的数据包,当这些发送方的数据包被接收方处理后又会向对方发送响应,所以一来一回需要等待 2 倍的时间。
  2. 2MSL的时间是从客户端接收到 FIN 后发送 ACK 开始计时的。如果在 TIME-WAIT 时间内,因为客户端的 ACK 没有传输到服务端,客户端又接收到了服务端重发的 FIN 报文,那么 2MSL 时间将重新计时。
  3. 保证Client发送的最后一个ACK报文段能够顺利地到达Server
  4. 保证本次连接所有报文从网络中消失。(不影响下一次连接)

4. 为什么需要 TIME_WAIT 状态?

  1. 防止具有相同四元组的旧数据包被收到;

有相同端口的 TCP 连接被复用后,被延迟的相同四元组的数据包抵达了客户端,那么客户端是有可能正常接收这个过期的报文,这就会产生数据错乱等严重的问题。
经过2MSL这个时间,足以让两个方向上的数据包都被丢弃,使得原来连接的数据包在网络中都自然消失,再出现的数据包一定都是新建立连接所产生的。

  1. 保证被动关闭连接的一方能被正确的关闭,即保证最后的 ACK 能让被动关闭方接收,从而帮助其正常关闭;

最后的ACK如果丢失,客户端直接进入close,服务端一直在等待ACK状态。当客户端发起建立连接的SYN请求,服务端会发送RST报文回应,连接建立会关闭。

如果 TIME-WAIT 等待足够长的情况就会遇到两种情况:
服务端正常收到四次挥手的最后一个 ACK报文,则服务端正常关闭连接。
服务端没有收到四次挥手的最后一个 ACK报文时,则会重发 FIN关闭连接报文并等待新的 ACK报文。

5. TIME_WAIT 过多有什么危害?

  1. 内存资源占用;
  2. 对端口资源的占用,一个 TCP 连接至少消耗一个本地端口;如果发起连接一方的 TIME_WAIT 状态过多,占满了所有端口资源,则会导致无法创建新连接。

参考

网络7层协议,4层,5层?理清容易混淆的几个概念
网络五层协议
TCP数据段格式+UDP数据段格式详解
TCP三次握手问的这么详细
TCP四次挥手详
小谈TCP协议中的Ack和Seq号

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 204,590评论 6 478
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 86,808评论 2 381
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 151,151评论 0 337
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 54,779评论 1 277
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 63,773评论 5 367
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 48,656评论 1 281
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 38,022评论 3 398
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 36,678评论 0 258
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 41,038评论 1 299
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,659评论 2 321
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 37,756评论 1 330
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 33,411评论 4 321
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 39,005评论 3 307
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 29,973评论 0 19
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,203评论 1 260
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 45,053评论 2 350
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 42,495评论 2 343

推荐阅读更多精彩内容