共计 4191 个字符，预计需要花费 11 分钟才能阅读完成。
什么 TCP
https://www.processon.com/diagraming/5e154137e4b0bcfb73390288
互联网由一整套协定形成。TCP 只是其中的一层，有着本人的分工。TCP 是以太网协定和 IP 协定的下层协定，也是应用层协定的上层协定。
IP 层是「不牢靠」的，它不保障网络包的交付、不保障网络包的按序交付、也不保障网络包中的数据的完整性。
如果须要保障网络数据包的可靠性，那么就须要由下层（传输层）的 TCP 协定来负责。
因为 TCP 是一个工作在 传输层 的牢靠 数据传输的服务，它能确保接收端接管的网络包是 无损坏、无距离、非冗余和按序的。
TCP 是 面向连贯的、牢靠的、基于字节流 的传输层通信协议。
面向连贯：肯定是「一对一」能力连贯，不能像 UDP 协定 能够一个主机同时向多个主机发送音讯，也就是一对多是无奈做到的；
牢靠的：无论的网络链路中呈现了怎么的链路变动，TCP 都能够保障一个报文肯定可能达到接收端；
字节流：音讯是「没有边界」的，所以无论咱们音讯有多大都能够进行传输。并且音讯是「有序的」，当「前一个」音讯没有收到的时候，即便它先收到了前面的字节曾经收到，那么也不能扔给应用层去解决，同时对「反复」的报文会主动抛弃。
TCP 数据包的组成
序列号 ：在建设连贯时由计算机生成的随机数作为其初始值，通过 SYN 包传给接收端主机，每发送一次数据，就「累加」一次该「数据字节数」的大小。 用来解决网络包乱序问题。
确认应答号 ：指下一次「冀望」收到的数据的序列号，发送端收到这个确认应答当前能够认为在这个序号以前的数据都曾经被失常接管。 用来解决不丢包的问题。
管制位：
ACK：该位为 1 时，「确认应答」的字段变为无效，TCP 规定除了最后建设连贯时的 SYN 包之外该位必须设置为 1。
RST：该位为 1 时，示意 TCP 连贯中出现异常必须强制断开连接。
SYC：该位为 1 时，示意心愿建设连，并在其「序列号」的字段进行序列号初始值的设定。
FIN：该位为 1 时，示意今后不会再有数据发送，心愿断开连接。当通信完结心愿断开连接时，通信单方的主机之间就能够相互交换 FIN 地位为 1 的 TCP 段。
TCP 四元组能够惟一的确定一个连贯，四元组包含如下：
源地址，源端口，目标地址，目标端口
Wireshark 抓包工具
Wireshark 就是最罕用的网络抓包和剖析工具，更是剖析网络性能必不可少的利器。它除了能够抓包外，还提供了可视化剖析网络包的图形页面。
装置
关上下载好的软件包, 将Wireshark.app 拖动到Applications 中并双击Install ChmodBPF.pkg, 只有装置了这个, 能力捕捉数据包
应用
以拜访 www.baidu.com 为例
ping www.baidu.com 查看 IP
curl www.baidu.com
（只想查看一下三资握手, 间接关上页面的话会有一大堆的申请, 影响查看, 所以采纳 curl 的形式）
在 Wireshark 通过 filter 外面监听百度的 ip 地址，失去 TCP 三次握手四次挥手的信息：
TCP 三次握手四次挥手
HTTP 是基于 TCP 协定进行传输的，那么：
- 最开始的 3 个包就是 TCP 三次握手建设连贯的包
- 两头是 HTTP 申请和响应的包
- 而最初的 3 个包则是 TCP 断开连接的挥手包
Wireshark 能够用时序图的形式显示数据包交互的过程，从菜单栏中，点击 统计 (Statistics) -> 流量图 (Flow Graph)，而后，在弹出的界面中的「流量类型」抉择「TCP Flows」，整个过程中 TCP 流的执行过程：
这里 Seq=0，是因为 Wireshark 工具帮咱们做了优化，它默认显示的是序列号 seq 是相对值，而不是实在值。客户端和服务端的序列号实际上是不同的，序列号是一个随机值。
TCP 三次握手
- 一开始，客户端和服务端都处于 CLOSED 状态。先是服务端被动监听某个端口，处于 LISTEN 状态
- 客户端会随机初始化序号（client\_isn），将此序号置于 TCP 首部的「序号」字段中，同时把 SYN 标记地位为 1，示意 SYN 报文。接着把第一个 SYN 报文发送给服务端，示意向服务端发动连贯，该报文不蕴含应用层数据，之后客户端处于 SYN-SENT 状态。
- 服务端收到客户端的 SYN 报文后，首先服务端也随机初始化本人的序号（server\_isn），将此序号填入 TCP 首部的「序号」字段中，其次把 TCP 首部的「确认应答号」字段填入 client\_isn + 1, 接着把 SYN 和 ACK 标记地位为 1。最初把该报文发给客户端，该报文也不蕴含应用层数据，之后服务端处于 SYN-RCVD 状态。
- 客户端收到服务端报文后，还要向服务端回应最初一个应答报文，首先该应答报文 TCP 首部 ACK 标记地位为 1，其次「确认应答号」字段填入 server\_isn + 1，最初把报文发送给服务端，这次报文能够携带客户到服务器的数据，之后客户端处于 ESTABLISHED 状态。服务器收到客户端的应答报文后，也进入 ESTABLISHED 状态。
一旦实现三次握手，单方都处于 ESTABLISHED 状态，此致连贯就已建设实现，客户端和服务端就能够互相发送数据了。
* 第三次握手是能够携带数据的，前两次握手是不能够携带数据的，这也是面试常问的题。*
为什么是三次握手
为什么三次握手才能够初始化 Socket、序列号和窗口大小并建设 TCP 连贯。**
接下来以三个方面剖析三次握手的起因：
- 三次握手才能够阻止反复历史连贯的初始化（次要起因）
客户端间断发送屡次 SYN 建设连贯的报文，在网络拥挤等状况下：
一个「旧 SVN 报文」比「最新的 SYN」报文早达到了服务端；那么此时服务端就会回一个 SYN + ACK 报文给客户端；客户端收到后能够依据本身的上下文，判断这是一个历史连贯（序列号过期或超时），那么客户端就会发送 RST 报文给服务端，示意停止这一次连贯。
如果是两次握手连贯，就不能判断以后连贯是否是历史连贯，三次握手则能够在客户端（发送方）筹备发送第三次报文时，客户端因有足够的上下文来判断以后连贯是否是历史连贯。
- 三次握手才能够同步单方的初始序列号
TCP 协定的通信单方，都必须保护一个「序列号」，序列号是牢靠传输的一个关键因素。它的作用：接管方能够去除反复的数据；接管方能够依据数据包的序列号按序接管；能够标识发送进来的数据包中，哪些是曾经被对方收到的；
当客户端发送携带「初始序列号」的 SYN 报文的时候，须要服务端回一个 ACK 应答报文，示意客户端的 SVN 报文已被服务端胜利接管，那当服务端发送「初始序列号」给客户端的时候，仍然也要失去客户端的应答回应，这样一来一回，能力确保单方的初始序列号能被牢靠的同步。**
- 三次握手才能够防止资源节约
TCP 四次挥手
- 客户端打算敞开连贯，此时会发送一个 TCP 首部 FIN 标记位被置为 1 的报文，也即 FIN 报文，之后客户端进入 FIN\_WAIT\_1 状态。
- 服务端收到该报文后，就向客户端发送 ACK 应答报文，接着服务端进入 CLOSED\_WAIT 状态。
- 客户端收到服务端的 ACK 应答报文后，之后进入 FIN\_WAIT\_2 状态。
- 期待服务端解决完数据后，也向客户端发送 FIN 报文，之后服务端进入 LAST\_ACK 状态。
- 客户端收到服务端的 FIN 报文后，回一个 ACK 应答报文，之后进入 TIME\_WAIT 状态
- 服务器收到了 ACK 应答报文后，就进入了 CLOSE 状态，至此服务端曾经实现连贯的敞开。
- 客户端在通过 2MSL 一段时间后，主动进入 CLOSE 状态，至此客户端也实现连贯的敞开。
被动敞开连贯的，才有 TIME\_WAIT 状态。**
从下面过程可知，服务端通常须要期待实现数据的发送和解决，所以服务端的 ACK 和 FIN 个别都会离开发送，从而比三次握手导致多了一次。
存在 TIME\_WAIT 的两个起因：1。终止牢靠的 TCP 全双工连贯 2. 容许旧的反复数据包在网络中隐没
TIME\_WAIT 期待的工夫是 2MSL**
MSL 是 Maximum Segment Lifetime，报文最大生存工夫，它是任何报文在网络上存在的最长工夫，超过这个工夫报文将被抛弃。因为 TCP 报文基于是 IP 协定的，而 IP 头中有一个 TTL 字段，是 IP 数据报能够通过的最大路由数，每通过一个解决他的路由器此值就减 1，当此值为 0 则数据报将被抛弃，同时发送 ICMP 报文告诉源主机。
TIME\_WAIT 期待 2 倍的 MSL，比拟正当的解释是：网络中可能存在来自发送方的数据包，当这些发送方的数据包被接管方解决后又会向对方发送响应，所以 一来一回须要期待 2 倍的工夫。
TCP 流量管制
TCP 为了避免发送方无脑的发送数据，导致接管方缓冲区被填满，所以就有了滑动窗口的机制，它可利用接管方的接管窗口来管制发送方要发送的数据量，也就是流量管制。
接管窗口是由接管方指定的值，存储在 TCP 头部中，它能够通知发送方本人的 TCP 缓冲空间区大小，这个缓冲区是给应用程序读取数据的空间：
- 如果应用程序读取了缓冲区的数据，那么缓冲空间区的就会把被读取的数据移除
- 如果应用程序没有读取数据，则数据会始终滞留在缓冲区。
接管窗口的大小，是在 TCP 三次握手中协商好的，后续数据传输时，接管方发送确认应答 ACK 报文时，会携带以后的接管窗口的大小，以此来告知发送方。
TCP 和 UDP 区别
1. 连贯**
TCP 是面向连贯的传输层协定，传输数据前先要建设连贯。UDP 是不须要连贯，即刻传输数据。
2. 服务对象**
TCP 是一对一的两点服务，即一条连贯只有两个端点。UDP 反对一对一、一对多、多对多的交互通信
3. 可靠性**
TCP 是牢靠交付数据的，数据能够无差错、不失落、不反复、按需达到。UDP 是尽最大致力交付，不保障牢靠交付数据。
4. 拥塞管制、流量管制**
TCP 有拥塞管制和流量管制机制，保障数据传输的安全性。UDP 则没有，即便网络十分拥挤了，也不会影响 UDP 的发送速率。
5. 首部开销**
TCP 首部长度较长，会有肯定的开销，首部在没有应用「选项」字段时是 20 个字节，如果应用了「选项」字段则会变长的。UDP 首部只有 8 个字节，并且是固定不变的，开销较小。
TCP 和 UDP 利用场景：**
因为 TCP 是面向连贯，能保证数据的可靠性交付，因而常常用于：
FTP 文件传输 HTTP / HTTPS
因为 UDP 面向无连贯，它能够随时发送数据，再加上 UDP 自身的解决既简略又高效，因而常常用于：
包总量较少的通信，如 DNS、SNMP 等视频、音频等多媒体通信播送通信