共计 2733 个字符，预计需要花费 7 分钟才能阅读完成。
如果你 只是 在编写 Web 利用，你齐全无需理解三次握手的细节——因为我 真的 没想到利用场景，如果你晓得，能够通知我。
故事要从我第一次编写长连贯利用说起，从 HTTP 下的需要开发，到编写 TCP 长连贯利用，于我而言，假使不了解握手流程，就很难了解：
- 什么是数据包？
- 如何解析一个包？
- 握手流程里的事件用处？
- 怎么的体现是传输出错？
- 如果呈现传输问题，哪个步骤出了错？该怎么解决？
- 框架有问题，想提个修复 PR，但这个代码正文说 MSS？MTU？
- 我须要反对自有包格局，该怎么写解析、封装？
- TCP/UDP/HTTP 等理论应用的协定（此处并非指某一层，譬如 HTTP 也是基于 TCP，不是说这个），性能差距差在哪里？
- etc.
如果此时你选用 Socket.IO 或相似的框架，状况还好一些，如果没有必要，你无需关注数据包问题——当数据出现异常时，了解握手有时候会成为解决问题的必须条件。
这就是我对 TCP 握手第一次产生趣味的时刻。
TCP 握手流程
SYN：Synchronize；
ACK：Acknowledge；
FIN：Finished。
| 发起方 | 接管方 | 意义 |
|---|---|---|
| 发送：SYN + A 序列号；状态：SYN-SENT | ||
| 发送：ACK-SYN + A 序列号 + B 序列号 状态：SYN-RCVD | 接管方确认：接管方可收，发动方可发 | |
| 发送：ACK，状态：Established | 发起方确认单方可收发，我方序列号被承受 | |
| 状态：Established | 接管方确认单方可收发，我方序列号被承受 | |
| 通信中 …. | 通信中 …. | |
| 发送：FIN | 发起方想完结连贯 | |
| 发送：ACK | 接管方理解发起方想完结连贯 | |
| 发起方收到 | 发起方理解接管方已通晓 | |
| 发送：FIN | 接管方知晓数据传完，可敞开 | |
| 发送：ACK | 发动方知晓数据传完，可敞开 | |
| 接管方收到，不再维持连贯 | 接管方知晓发起方已通晓连贯可敞开 | |
| 期待 2 个 MSL 工夫 … 不再维持连贯 | 发起方需确认最初音讯未丢包，则敞开本身 |
序列号
TCP 协定采纳 序列号 +1的形式，来确认单方通信的有序性。
在很老的 TCP 版本中，该起始序列号是固定的——这导致了轻松的连贯劫持，只须要模仿固定的序列号即可。
不必放心，后续版本已将它降级为随机起始值。且对采纳了 SSL / HTTPS 等平安协定的服务，这种问题简直不存在。
注意安全，仍有其余劫持可能运作，譬如复合了 IP 坑骗或自觉劫持等伎俩后，发动的钓鱼、中间人攻打等劫持形式。
MSL 工夫
数据段的最大生命工夫（Maximum segment lifetime），这里有三个重点：
- 超过此工夫的数据段将被抛弃（数据段或叫报文？）。
- 在 Linux，你能够通过 tcp_fin_timeout 和 tcp_keepalive_time 来调整它。
- 如果你喜爱 Windows Service，能够尝试 How Do I Reduce the Time for Canceling TCP Connections in TIME_WAIT State on Windows
- 1981 年的原始协定规定 MSL = 120s，实际上，Linux 内核将其缩短为 30s——这对于某些利用来说，依然过长了。
SYN 泛洪攻打
指：
- 通过大量结构连贯，且在最初一步不发送 ACK 数据包，从而结构半开连贯；
- 服务端为连贯分配资源后，长时间维持无用连贯的状况（思考 MSL 工夫，这个连贯会存在很久）。
- 当大量的连贯被建设、分配资源、搁置后，整个服务进入停摆状态。
能够通过回收最先创立的 TCP 半开连贯、IP 甄别并临时拉黑，云服务商还会有握手沙盒服务等。
让咱们回到 TCP 自身。
超时重传
TCP 的安全性有各种机制保障，超时重传就是其中之一。
超时重传工夫，也叫 RTO 工夫（Retransmission-TimeOut），它如何如何发挥作用呢？
- 当一个包传输 RTO 工夫后依然没有后果，则确认包失落；
- 当确认包失落后，发送端将从新发送信息给对方，此时 RTO 工夫加倍；
- 反复上述过程，重试 3 次后仍有效，放弃。
RTT 工夫
往返时延工夫（Round-Trip-Time），这里介绍这个概念，次要是因为 RTO 工夫会受到 RTT 工夫的影响。
首先，RTT 计算形式：一端发送 SYN 包起，另一端回复 SYN-ACK 包完结。
接着，思考到网络传输的时延和不稳固，TCP 会计算出 SRTT（Smoothed RTT），作为新 RTO 的计算系数之一。
（具体计算形式能够参考 RFC 的相干文档，写的很明确，附在了援用中）
ARQ 协定
主动重传申请（Automatic Repeat-reQuest），它自身只是一个协定，各种平安通信协定都有对应的实现。
当数据包超时后，会触发 ARQ 机制进行重传。
TCP 包细节
标头
TCP 包中，标头是指 IP Header、TCP Header 这部分，惯例而言，两者均为 20 字节（能够扩大，但简直没有须要）。
标头用于指定各种地址、协定、包相干的信息：
须要留神的是：源 / 指标端口号、序列号、管制标记（ACK 等），它们都在标头中。
载荷
追随在标头后，是数据包的载荷局部，这外面则蕴含了数据包的具体数据。
少数应用层开发者都更关注载荷，而非标头。
MTU 尺寸
包头 + 载荷，形成了一个数据包的尺寸，那咱们用 MTU（Maximum transmission unit，最大传输单位）来形容它。
若一次数据传输超过这个单位，将进行分段传输。
MSS 尺寸
MSS（最大分段大小）用于标识数据块的尺寸，也就是：MTU – 标头尺寸 = MSS。
此处有 MSS 协商 的概念，连贯单方在握手的 SYN 阶段确认彼此的 MSS 尺寸，同时以最小值作为本次连贯的信息替换尺寸。
这个协商并非强制进行的，可能一端并不会传输本人的 MSS 尺寸，导致：
如标头后退出了其余信息（IPsec、GRE 隧道传输等信息），可能会导致 MTU 超过 1500 的常见尺寸，造成荫蔽的包体内容不全。
援用
本文参考或援用以下材料，在此致谢：
The TCP / IP Guide
淘宝二面，面试官竟然把 TCP 三次握手问的这么具体
Understanding RTT Impact on TCP Retransmissions
TCP 的个性 – # 口试面试常识整顿
Why is TCP MSL so long? – ServerFault
RFC – 6298
引申 1：找材料时看到有博主示意，抓包时理解 TCP 很有用，这一点对 tcpdump、fiddler 是有意义的，可如果你是用 Charles、Chrome Console 的 Network 抓包，它曾经把 懒人化 做到极致了，其实你须要的数据，98% 都只是传输信息，而非包数据。
引申 2：TCP 的相干知识点很短缺，导致写的有点久。很多乏味的内容也没有说到，譬如：
- TCP 的流量管制、拥塞管制，这是 TCP 重要的设计概念，对 KCP 也有不小的影响；
- TCP 的攻防机制，与 UDP 攻防的不同点。
- TCP 的配置，在 Linux 环境的性能优化，出名的网游 WOW（魔兽世界）就采纳了 TCP 协定。
可能后续会写一些跟进文章来解释。
