共计 8223 个字符，预计需要花费 21 分钟才能阅读完成。
越致力，越侥幸，
本文已珍藏在 GitHub 中 JavaCommunity, 外面有面试分享、源码剖析系列文章，欢送珍藏，点赞
https://github.com/Ccww-lx/Ja…
TCP 简介
为什么须要 TCP 协定？TCP 工作在哪一层？
IP 层是「不牢靠」的，它不保障网络包的交付、不保障网络包的按序交付、也不保障网络包中的数据的完整性。
OSI 参考模型与 TCP/IP 的关系
如果须要保障网络数据包的可靠性，那么就须要由下层（传输层）的 TCP 协定来负责。
因为 TCP 是一个工作在 传输层 的牢靠 数据传输的服务，它能确保接收端接管的网络包是 无损坏、无距离、非冗余和按序的。那么 TCP 是什么呢？
什么是 TCP？
TCP 是 面向连贯的、牢靠的、基于字节流 的传输层通信协议。
- 面向连贯：肯定是「一对一」能力连贯，不能像 UDP 协定 能够一个主机同时向多个主机发送音讯，也就是一对多是无奈做到的；
- 牢靠的：无论的网络链路中呈现了怎么的链路变动，TCP 都能够保障一个报文肯定可能达到接收端；
- 字节流：音讯是「没有边界」的，所以无论咱们音讯有多大都能够进行传输。并且音讯是「有序的」，当「前一个」音讯没有收到的时候，即便它先收到了前面的字节曾经收到，那么也不能扔给应用层去解决，同时对「反复」的报文会主动抛弃。
其中，面向连贯意味着两个应用 TCP 的利用（通常是一个客户和一个服务器）在彼此替换数据之前必须先建设一个 TCP 连贯。
- 在一个 TCP 连贯中，仅有两方进行彼此通信。
- 而字节流服务意味着两个应用程序通过 TCP 链接替换 8bit 字节形成的字节流，TCP 不在字节流中插入记录标识符。
对于可靠性，TCP 通过以下形式进行保障：
- 数据包校验：目标是检测数据在传输过程中的任何变动，若校验出包有错，则抛弃报文段并且不给出响应，这时 TCP 发送数据端超时后会重发数据。
- 对失序数据包重排序：既然 TCP 报文段作为 IP 数据报来传输，而 IP 数据报的达到可能会失序，因而 TC P 报文段的达到也可能会失序。TCP 将对失序数据进行从新排序，而后才交给应用层。
- 抛弃反复数据：对于反复数据，可能抛弃反复数据。
- 应答机制：当 TCP 收到发自 TCP 连贯另一端的数据，它将发送一个确认。这个确认不是立刻发送，通常将推延几分之一秒。
- 超时重发：当 TCP 收回一个段后，它启动一个定时器，期待目标端确认收到这个报文段。如果不能及时收到一个确认，将重发这个报文段。
- 流量管制：TCP 连贯的每一方都有固定大小的缓冲空间。TCP 的接收端只容许另一端发送接收端缓冲区所能接收的数据，这能够避免较快主机以致较慢主机的缓冲区溢出，这就是流量管制。TCP 应用的流量控制协议是可变大小的 滑动窗口协定。
那么 TCP 的结构是怎么样的呢？
TCP 头部格局
咱们先来看看 TCP 头部格局：
序列号 ：在建设连贯时由计算机生成的随机数作为其初始值，通过 SYN 包传给接收端主机，每发送一次数据，就「累加」一次该「数据字节数」的大小。 用来解决网络包乱序问题。
确认应答号 ：指下一次「冀望」收到的数据的序列号，发送端收到这个确认应答当前能够认为在这个序号以前的数据都曾经被失常接管。 用来解决不丢包的问题。
标记位：
- ACK：该位为
1时，「确认应答」的字段变为无效，TCP 规定除了最后建设连贯时的SYN包之外该位必须设置为1。 - RST：该位为
1时，示意 TCP 连贯中出现异常必须强制断开连接。 - SYC：该位为
1时，示意心愿建设连，并在其「序列号」的字段进行序列号初始值的设定。 - FIN：该位为
1时，示意今后不会再有数据发送，心愿断开连接。当通信完结心愿断开连接时，通信单方的主机之间就能够相互交换FIN地位为 1 的 TCP 段。
窗口
滑动窗口大小，这个字段是接收端用来告知发送端本人还有多少缓冲区能够承受数据。于是发送端能够依据这个接收端的解决能力来发送数据，而不会导致接收端解决不过去。（以此管制发送端发送数据的速率，从而达到流量管制。）窗口大小时一个 16bit 字段，因此窗口大小最大为 65535。
在理解了根底 TCP 实践后，看看 TCP 是如何工作的呢? 首先看看 TCP 连贯建设
TCP 连贯建设
TCP 是面向连贯的协定，所以应用 TCP 前必须先建设连贯，而 建设连贯是通过三次握手而进行的。
- 一开始，客户端和服务端都处于
CLOSED状态。先是服务端被动监听某个端口，处于LISTEN状态
第一个报文—— SYN 报文
- 客户端会随机初始化序号（
client_isn），将此序号置于 TCP 首部的「序号」字段中，同时把SYN标记地位为1，示意SYN报文。接着把第一个 SYN 报文发送给服务端，示意向服务端发动连贯，该报文不蕴含应用层数据，之后客户端处于SYN-SENT状态。
第二个报文 —— SYN + ACK 报文
- 服务端收到客户端的
SYN报文后，首先服务端也随机初始化本人的序号（server_isn），将此序号填入 TCP 首部的「序号」字段中，其次把 TCP 首部的「确认应答号」字段填入client_isn + 1, 接着把SYN和ACK标记地位为1。最初把该报文发给客户端，该报文也不蕴含应用层数据，之后服务端处于SYN-RCVD状态。
第三个报文 —— ACK 报文
- 客户端收到服务端报文后，还要向服务端回应最初一个应答报文，首先该应答报文 TCP 首部
ACK标记地位为1，其次「确认应答号」字段填入server_isn + 1，最初把报文发送给服务端，这次报文能够携带客户到服务器的数据，之后客户端处于ESTABLISHED状态。 - 服务器收到客户端的应答报文后，也进入
ESTABLISHED状态。
从下面的过程能够发现 第三次握手是能够携带数据的，前两次握手是不能够携带数据的，这也是面试常问的题。
一旦实现三次握手，单方都处于 ESTABLISHED 状态，此致连贯就已建设实现，客户端和服务端就能够互相发送数据了。
为什么是三次握手？不是两次、四次？
能够从以下的三个方面剖析为什么是三次握手，不是两次、四次的起因：
- 三次握手才能够阻止历史反复连贯的初始化（次要起因）
- 三次握手才能够同步单方的初始序列号
- 三次握手才能够防止资源节约
起因一：防止历史连贯
简略来说，三次握手的 首要起因是为了避免旧的反复连贯初始化造成凌乱。
网络环境是盘根错节的，往往并不是如咱们冀望的一样，先发送的数据包，就先达到指标主机，反而它很骚，可能会因为网络拥挤等乌七八糟的起因，会使得旧的数据包，先达到指标主机，那么这种状况下 TCP 三次握手是如何防止的呢？
三次握手防止历史连贯
客户端间断发送屡次 SYN 建设连贯的报文，在网络拥挤等状况下：
- 一个「旧 SYN 报文」比「最新的 SYN」报文早达到了服务端；
- 那么此时服务端就会回一个
SYN + ACK报文给客户端； - 客户端收到后能够依据本身的上下文，判断这是一个历史连贯（序列号过期或超时），那么客户端就会发送
RST报文给服务端，示意停止这一次连贯。
如果是两次握手连贯，就不能判断以后连贯是否是历史连贯，三次握手则能够在客户端（发送方）筹备发送第三次报文时，客户端因有足够的上下文来判断以后连贯是否是历史连贯：
- 如果是历史连贯（序列号过期或超时），则第三次握手发送的报文是
RST报文，以此停止历史连贯； - 如果不是历史连贯，则第三次发送的报文是
ACK报文，通信单方就会胜利建设连贯；
所以，TCP 应用三次握手建设连贯的最次要起因是 避免历史连贯初始化了连贯。
起因二：同步单方初始序列号
TCP 协定的通信单方，都必须保护一个「序列号」，序列号是牢靠传输的一个关键因素，它的作用：
- 接管方能够去除反复的数据；
- 接管方能够依据数据包的序列号按序接管；
- 能够标识发送进来的数据包中，哪些是曾经被对方收到的；
可见，序列号在 TCP 连贯中占据着十分重要的作用，所以当客户端发送携带「初始序列号」的 SYN 报文的时候，须要服务端回一个 ACK 应答报文，示意客户端的 SYN 报文已被服务端胜利接管，那当服务端发送「初始序列号」给客户端的时候，仍然也要失去客户端的应答回应，这样一来一回，能力确保单方的初始序列号能被牢靠的同步。
四次握手与三次握手
四次握手其实也可能牢靠的同步单方的初始化序号，但因为 第二步和第三步能够优化成一步，所以就成了「三次握手」。
而两次握手只保障了一方的初始序列号能被对方胜利接管，没方法保障单方的初始序列号都能被确认接管。
起因三：防止资源节约
如果只有「两次握手」，当客户端的 SYN 申请连贯在网络中阻塞，客户端没有接管到ACK 报文，就会从新发送 SYN，因为没有第三次握手，服务器不分明客户端是否收到了本人发送的建设连贯的 ACK 确认信号，所以每收到一个 SYN 就只能先被动建设一个连贯，这会造成什么状况呢？
如果客户端的 SYN 阻塞了，反复发送屡次 SYN 报文，那么服务器在收到申请后就会 建设多个冗余的有效链接，造成不必要的资源节约。
两次握手会造成资源节约
即两次握手会造成音讯滞留状况下，服务器反复承受无用的连贯申请 SYN 报文，而造成反复分配资源。
小结
TCP 建设连贯时，通过三次握手 能避免历史连贯的建设，能缩小单方不必要的资源开销，能帮忙单方同步初始化序列号。序列号可能保障数据包不反复、不抛弃和按序传输。
不应用「两次握手」和「四次握手」的起因：
- 「两次握手」：无奈避免历史连贯的建设，会造成单方资源的节约，也无奈牢靠的同步单方序列号；
- 「四次握手」：三次握手就曾经实践上起码牢靠连贯建设，所以不须要应用更多的通信次数。
TCP 连贯断开
天下没有不散的宴席，对于 TCP 连贯也是这样，TCP 断开连接是通过 四次挥手 形式。
单方都能够被动断开连接，断开连接后主机中的「资源」将被开释。
客户端被动敞开连贯 —— 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状态，至此客户端也实现连贯的敞开。
你能够看到，每个方向都须要 一个 FIN 和一个 ACK，因而通常被称为 四次挥手。
这里一点须要留神是：被动敞开连贯的，才有 TIME_WAIT 状态。
为什么挥手须要四次？
再来回顾下四次挥手单方发 FIN 包的过程，就能了解为什么须要四次了。
- 敞开连贯时，客户端向服务端发送
FIN时，仅仅示意客户端不再发送数据了然而还能接收数据。 - 服务器收到客户端的
FIN报文时，先回一个ACK应答报文，而服务端可能还有数据须要解决和发送，等服务端不再发送数据时，才发送FIN报文给客户端来表示同意当初敞开连贯。
从下面过程可知，服务端通常须要期待实现数据的发送和解决，所以服务端的 ACK 和FIN 个别都会离开发送，从而比三次握手导致多了一次。
为什么 TIME_WAIT 期待的工夫是 2MSL？
MSL 是 Maximum Segment Lifetime，报文最大生存工夫，它是任何报文在网络上存在的最长工夫，超过这个工夫报文将被抛弃。因为 TCP 报文基于是 IP 协定的，而 IP 头中有一个 TTL 字段，是 IP 数据报能够通过的最大路由数，每通过一个解决他的路由器此值就减 1，当此值为 0 则数据报将被抛弃，同时发送 ICMP 报文告诉源主机。
MSL 与 TTL 的区别：MSL 的单位是工夫，而 TTL 是通过路由跳数。所以 MSL 应该要大于等于 TTL 耗费为 0 的工夫，以确保报文已被天然沦亡。
TIME_WAIT 期待 2 倍的 MSL，比拟正当的解释是：网络中可能存在来自发送方的数据包，当这些发送方的数据包被接管方解决后又会向对方发送响应，所以 一来一回须要期待 2 倍的工夫。
比方，如果被动敞开方没有收到断开连接的最初的 ACK 报文，就会触发超时重发 Fin 报文，另一方接管到 FIN 后，会重发 ACK 给被动敞开方，一来一去正好 2 个 MSL。
2MSL 的工夫是从 客户端接管到 FIN 后发送 ACK 开始计时的。如果在 TIME-WAIT 工夫内，因为客户端的 ACK 没有传输到服务端，客户端又接管到了服务端重发的 FIN 报文，那么 2MSL 工夫将从新计时。
在 Linux 零碎里 2MSL 默认是 60 秒，那么一个 MSL 也就是 30 秒。Linux 零碎停留在 TIME_WAIT 的工夫为固定的 60 秒。
其定义在 Linux 内核代码里的名称为 TCP_TIMEWAIT_LEN：
#define TCP_TIMEWAIT_LEN (60*HZ) /* how long to wait to destroy TIME-WAIT state, about 60 seconds */如果要批改 TIME_WAIT 的工夫长度，只能批改 Linux 内核代码里 TCP_TIMEWAIT_LEN 的值，并从新编译 Linux 内核。
为什么须要 TIME_WAIT 状态？
被动发动敞开连贯的一方，才会有 TIME-WAIT 状态。
须要 TIME-WAIT 状态，次要是两个起因：
- 避免具备雷同「源、指标信息」的「旧」数据包被收到；
- 保障「被动敞开连贯」的一方能被正确的敞开，即保障最初的 ACK 能让被动敞开方接管，从而帮忙其失常敞开；
起因一：避免旧连贯的数据包
假如 TIME-WAIT 没有等待时间或工夫过短，被提早的数据包到达后会产生什么呢？
接管到历史数据的异样
- 如上图黄色框框服务端在敞开连贯之前发送的
SEQ = 301报文，被网络提早了。 - 这时有雷同端口的 TCP 连贯被复用后，被提早的
SEQ = 301到达了客户端，那么客户端是有可能失常接管这个过期的报文，这就会产生数据错乱等重大的问题。
所以，TCP 就设计出了这么一个机制，通过 2MSL 这个工夫，足以让两个方向上的数据包都被抛弃，使得原来连贯的数据包在网络中都天然隐没，再呈现的数据包肯定都是新建设连贯所产生的。
起因二：保障连贯正确敞开
TIME-WAIT 作用是 期待足够的工夫以确保最初的 ACK 能让被动敞开方接管，从而帮忙其失常敞开。
假如 TIME-WAIT 没有等待时间或工夫过短，断开连接会造成什么问题呢？
没有确保失常断开的异样
- 如上图红色框框客户端四次挥手的最初一个
ACK报文如果在网络中被失落了，此时如果客户端TIME-WAIT过短或没有，则就间接进入了CLOSE状态了，那么服务端则会始终处在LASE-ACK状态。 - 当客户端发动建设连贯的
SYN申请报文后，服务端会发送RST报文给客户端，连贯建设的过程就会被终止。
如果 TIME-WAIT 期待足够长的状况就会遇到两种状况：
- 服务端失常收到四次挥手的最初一个
ACK报文，则服务端失常敞开连贯。 - 服务端没有收到四次挥手的最初一个
ACK报文时，则会重发FIN敞开连贯报文并期待新的ACK报文。
所以客户端在 TIME-WAIT 状态期待 2MSL 工夫后，就能够 保障单方的连贯都能够失常的敞开。
TIME_WAIT 过多有什么危害？
如果服务器有处于 TIME-WAIT 状态的 TCP，则阐明是由服务器方被动发动的断开申请。
过多的 TIME-WAIT 状态次要的危害有两种：
- 第一是内存资源占用；
- 第二是对端口资源的占用，一个 TCP 连贯至多耗费一个本地端口；
第二个危害是会造成重大的结果的，要晓得，端口资源也是无限的，个别能够开启的端口为 32768～61000，也能够通过如下参数设置指定
net.ipv4.ip_local_port_range如果服务端 TIME_WAIT 状态过多，占满了所有端口资源，则会导致无奈创立新连贯。
如何优化 TIME_WAIT？
这里给出优化 TIME-WAIT 的几个形式，都是有利有弊：
- 关上 net.ipv4.tcp_tw_reuse 和 net.ipv4.tcp_timestamps 选项；
- net.ipv4.tcp_max_tw_buckets
- 程序中应用 SO_LINGER，利用强制应用 RST 敞开。
形式一：net.ipv4.tcp_tw_reuse 和 tcp_timestamps
如下的 Linux 内核参数开启后，则能够 复用处于 TIME_WAIT 的 socket 为新的连贯所用。
net.ipv4.tcp_tw_reuse = 1应用这个选项，还有一个前提，须要关上对 TCP 工夫戳的反对，即
net.ipv4.tcp_timestamps=1（默认即为 1）这个工夫戳的字段是在 TCP 头部的「选项」里，用于记录 TCP 发送方的以后工夫戳和从对端接管到的最新工夫戳。
因为引入了工夫戳，咱们在后面提到的 2MSL 问题就不复存在了，因为反复的数据包会因为工夫戳过期被天然抛弃。
舒适揭示：net.ipv4.tcp_tw_reuse要慎用，因为应用了它就必然要关上工夫戳的反对 net.ipv4.tcp_timestamps， 当客户端与服务端主机工夫不同步时，客户端的发送的音讯会被间接回绝掉。敖丙在工作中就遇到过。。。排查了十分的久
形式二：net.ipv4.tcp_max_tw_buckets
这个值默认为 18000，当零碎中处于 TIME_WAIT 的连贯 一旦超过这个值时，零碎就会将所有的 TIME_WAIT 连贯状态重置。
这个办法过于暴力，而且治标不治本，带来的问题远比解决的问题多，不举荐应用。
形式三：程序中应用 SO_LINGER
咱们能够通过设置 socket 选项，来设置调用 close 敞开连贯行为。
struct linger so_linger;so_linger.l_onoff = 1;so_linger.l_linger = 0;setsockopt(s, SOL_SOCKET, SO_LINGER, &so_linger,sizeof(so_linger));如果 l_onoff 为非 0，且 l_linger 值为 0，那么调用 close 后，会立该发送一个 RST 标记给对端，该 TCP 连贯将跳过四次挥手，也就跳过了 TIME_WAIT 状态，间接敞开。
但这为逾越 TIME_WAIT 状态提供了一个可能，不过是一个十分危险的行为，不值得提倡。
如果曾经建设了连贯，然而客户端忽然呈现故障了怎么办？
TCP 有一个机制是 保活机制。这个机制的原理是这样的：
定义一个时间段，在这个时间段内，如果没有任何连贯相干的流动，TCP 保活机制会开始作用，每隔一个工夫距离，发送一个探测报文，该探测报文蕴含的数据非常少，如果间断几个探测报文都没有失去响应，则认为以后的 TCP 连贯曾经死亡，零碎内核将错误信息告诉给下层应用程序。
在 Linux 内核能够有对应的参数能够设置保活工夫、保活探测的次数、保活探测的工夫距离，以下都为默认值：
net.ipv4.tcp_keepalive_time=7200net.ipv4.tcp_keepalive_intvl=75 net.ipv4.tcp_keepalive_probes=9- tcp_keepalive_time=7200：示意保活工夫是 7200 秒（2 小时），也就 2 小时内如果没有任何连贯相干的流动，则会启动保活机制
- tcp_keepalive_intvl=75：示意每次检测距离 75 秒；
- tcp_keepalive_probes=9：示意检测 9 次无响应，认为对方是不可达的，从而中断本次的连贯。
也就是说在 Linux 零碎中，起码须要通过 2 小时 11 分 15 秒才能够发现一个「死亡」连贯。
这个工夫是有点长的，咱们也能够依据理论的需要，对以上的保活相干的参数进行设置。
如果开启了 TCP 保活，须要思考以下几种状况：
第一种，对端程序是失常工作的。当 TCP 保活的探测报文发送给对端, 对端会失常响应，这样 TCP 保活工夫会被重置，期待下一个 TCP 保活工夫的到来。
第二种，对端程序解体并重启。当 TCP 保活的探测报文发送给对端后，对端是能够响应的，但因为没有该连贯的无效信息，会产生一个 RST 报文，这样很快就会发现 TCP 连贯曾经被重置。
第三种，是对端程序解体，或对端因为其余起因导致报文不可达。当 TCP 保活的探测报文发送给对端后，杳无音信，没有响应，间断几次，达到保活探测次数后，TCP 会报告该 TCP 连贯曾经死亡。
文章起源：https://mp.weixin.qq.com/s/tH…
作者：小林 coding谢谢各位点赞，没点赞的点个赞反对反对
最初，微信搜《Ccww 技术博客》观看更多文章，也欢送关注一波
