TCP 为什么是三次握手，而不是两次或四次？

TCP 的三次握手而不是两次或四次，是经过深思熟虑的、为了保证通信的可靠性和高效性而设计的。下面我将详细解释其中的原因：

核心目标：建立一个可靠的、全双工的连接

TCP 的目标是建立一个可靠的、面向连接的、全双工的通信通道。这意味着：

可靠性： 确保数据能够按顺序、不丢失、不重复地送达。
面向连接： 在数据传输前，需要建立一个明确的连接。
全双工： 连接建立后，双方可以同时向对方发送和接收数据。

理解握手过程：建立双方的共识

三次握手是为了让通信的双方（我们称之为客户端 Client 和服务器端 Server）都明确地知道对方的存在、准备好发送数据以及接收数据。它解决了几个关键问题：

1. 确认双方都准备好了： 双方都需要知道对方已经准备好发送和接收数据。
2. 同步序列号： TCP 使用序列号来保证数据的顺序和可靠传输。在建立连接时，双方需要同步各自的初始序列号（ISN）。
3. 避免旧连接的数据干扰： 防止由于网络延迟导致的网络中残留的旧连接的重复数据包干扰新建立的连接。

为什么不是两次握手？

让我们假设只有两次握手，看看会发生什么问题：

两次握手设想：

1. Client > Server: SYN (Seq=X) 客户端发送一个 SYN 包，请求建立连接，并告知自己的初始序列号 X。
2. Server > Client: SYNACK (Seq=Y, ACK=X+1) 服务器收到 SYN 包后，同意建立连接，发送一个 SYNACK 包，告知自己的初始序列号 Y，并确认收到了客户端的 SYN 包（ACK=X+1）。
3. Client > Server: ACK (Seq=X+1, ACK=Y+1) 客户端收到 SYNACK 包后，发送一个 ACK 包，确认收到了服务器的 SYNACK 包。

问题出现在哪里？

想象一下这样的场景：

客户端发送第一个 SYN 包（Seq=X）。
由于网络问题，这个 SYN 包在网络中延迟了。
客户端认为连接没有建立成功，于是超时重传了一个 SYN 包（Seq=X）。
服务器收到了第一个 SYN 包，并回复了 SYNACK 包（Seq=Y, ACK=X+1）。
客户端收到了这个 SYNACK 包，并回复了 ACK 包（Seq=X+1, ACK=Y+1）。连接看起来已经建立。

然而！

此时，那个迟到的第一个 SYN 包（Seq=X）也到达了服务器。根据两步握手的规则，服务器认为客户端已经发送了 ACK 包（Seq=X+1, ACK=Y+1），并且客户端已经收到了 SYNACK 包。

现在服务器的状态是：它收到了一个 ACK 包（ACK=Y+1），表明客户端已经知道了它的 SYN 包。但实际上，这个 ACK 包是对应于客户端第二次发送的 SYN 包（Seq=X）的。而服务器误以为客户端收到了它的第一个 SYN 包，并成功回复了 ACK。

更严重的是，如果此时服务器错误地认为连接已经建立并开始发送数据，而客户端实际上并未收到服务器的 SYNACK 包（因为客户端的第一个 SYN 包迟到了，客户端以为连接未建立，并且它只对它收到的 SYN 包进行 ACK 响应），那么这个连接就会出现问题。

核心问题：服务器无法确认客户端是否收到了服务器的 SYNACK 包。

在两次握手中，客户端发送了 SYN，服务器回复了 SYNACK，然后客户端回复了 ACK。服务器发送 SYNACK 后，就认为连接可以建立并发送数据了。但是，它没有收到客户端的最终确认。如果客户端由于网络延迟而丢失了服务器的 SYNACK 包，或者客户端收到了 SYNACK 但未能发送 ACK 包，服务器就无法知道。服务器可能正在发送数据，而客户端却对此一无所知。

为什么不是四次握手？

四次握手会在三次握手的完整过程中再增加一个步骤。让我们看看如果增加一个步骤会如何：

四次握手设想：

1. Client > Server: SYN (Seq=X)
2. Server > Client: SYNACK (Seq=Y, ACK=X+1)
3. Client > Server: ACK (Seq=X+1, ACK=Y+1)
4. Server > Client: ACK (Seq=Y+1, ACK=X+2) （这是一个多余的确认）

问题在哪里？

在三次握手的最后一步，客户端已经发送了 ACK 包（Seq=X+1, ACK=Y+1）。这意味着：

客户端知道服务器的序列号 Y，并且已经成功接收了服务器的 SYNACK 包。
服务器知道客户端的序列号 X，并且已经成功接收了客户端的 SYN 包。
服务器通过 ACK=X+1 确认了客户端的 SYN 包。
客户端通过 ACK=Y+1 确认了服务器的 SYN 包。

此时，双方已经互相确认了对方的 SYN 包已经收到，并且双方都知道对方当前的序列号。服务器已经知道客户端准备好接收数据，客户端也知道服务器准备好接收数据。

为什么第四次握手是多余的？

第四次握手（Server > Client: ACK (Seq=Y+1, ACK=X+2)）的目的是什么？ 它是服务器对客户端的最后一次 ACK 的确认。但是，客户端在发送第三次握手的 ACK 包时，其序列号是 X+1，ACK 期望是 Y+1。一旦客户端收到服务器的 SYNACK，它就可以发送这个 ACK。服务器一旦收到这个 ACK，就知道客户端已经准备好并收到了 SYNACK。

多此一举的第四次握手并不能增加任何有用的信息，反而会增加额外的通信开销和时延。三次握手已经足够让双方建立起一个稳定的、可信的连接。

总结三次握手的作用：

1. SYN (Seq=X): 客户端发起连接请求，并告知自己的初始序列号 X。
2. SYNACK (Seq=Y, ACK=X+1): 服务器同意连接请求，告知自己的初始序列号 Y，并确认收到客户端的 SYN 包（ACK=X+1）。
3. ACK (Seq=X+1, ACK=Y+1): 客户端确认收到服务器的 SYNACK 包，告知自己的下一个期望序列号（X+1），并确认收到服务器的 SYN 包（ACK=Y+1）。

通过这三次交互：

Client > Server: Client 发送 SYN (X)，Server 回复 SYNACK (Y, ACK=X+1)。服务器确认收到了 Client 的 SYN。
Server > Client: Server 发送 SYNACK (Y)，Client 回复 ACK (X+1, ACK=Y+1)。客户端确认收到了 Server 的 SYN。

至此，双方都明确知道对方已经准备好发送和接收数据，并且已经同步了初始序列号。 这个过程是建立全双工连接的最小、且最有效的步骤。

举个生活中的例子：

想象你要给一个朋友打电话（假设你们从没打过电话，也不知道对方是否在线）。

你（客户端）打给朋友（服务器）： 你拨通电话，这是你的 SYN。
朋友接起电话，并对你说“喂，是我”： 这是朋友的 SYNACK。他表明自己在线，并听到了你的呼叫。
你听到朋友的声音，然后说“嗯，是我，你能听到我说话吗？”： 这是你的 ACK。你确认你听到了他，并且你准备开始对话。

这时，你们双方都知道对方已经接通了电话，并且可以正常通话了。这就是三次握手。

如果只有两次握手（你打过去，朋友接了），你挂了电话，朋友可能还以为你在通话中，但其实你已经挂断了。

如果四次握手，你打过去，朋友接了说“喂”，你说“喂，是我”，然后朋友又说“喂，我听到你了”，这显得有点多余。

结论：

TCP 的三次握手是为了解决在不可靠的网络中，如何可靠地建立一个全双工连接的问题。它通过三次信息交换，确保了：

双方都已准备好发送和接收数据。
双方都已了解对方的初始序列号。
避免了旧连接中的重复数据包对新连接的干扰。

两次握手不足以解决服务器无法确认客户端是否收到 SYNACK 的问题，而四次握手则是在满足可靠性需求后，增加了不必要的开销。因此，三次握手是 TCP 建立连接的“黄金标准”。

网友意见

来自我的公众号 『 YongHao 写东西的 Cache 』 打个小广告，还是希望写的东西有人看

分享一下见解，权当抛砖引玉

三次握手的误解与错误类比(RFC解读)

关于TCP三次握手几乎是应届毕业生面试常见的问题了，然而网上还很多比比皆是的错误，以知乎 TCP 为什么是三次握手，而不是两次或四次？ 上的热门答案为例子，第一个3.6K 次赞同的类比就是错误的：

       三次握手： “喂，你听得到吗？” “我听得到呀，你听得到我吗？” “我能听到你，今天 balabala……”     

同样这个107次赞同的类比也是错误的：

       握手和敬军礼一样，源自「敌我双方互相确认对方手里没有武器、无恶意」的仪式。（虽然双方互相请求确认需要四步，但由于中间的确认和请求是由同一个人执行的，所以合并成了一步）  正恩伸出手说：你看，我手里没有武器。（SYN）  朗普看了看说：嗯，确实没有。（ACK） 于是也伸出手说：你看，我手里也没有武器。（SYN） 正恩看了看说：嗯，看来你确实有诚意。（ACK）     

这两个类比就是想当然的错误，为什么会错误，看完全文相信你便了然于心。

另外还有一个就是在谢希仁著《计算机网络》第四版中，讲 “三次握手” 的目的是 “为了防止已失效的连接请求报文段突然又传送到了服务端，因而产生错误”，这个只能算是表因，并不涉及本质。

谢希仁版《计算机网络》中的例子是这样的，“已失效的连接请求报文段” 的产生在这样一种情况下：client 发出的第一个连接请求报文段并没有丢失，而是在某个网络结点长时间的滞留了，以致延误到连接释放以后的某个时间才到达 server。本来这是一个早已失效的报文段。但 server 收到此失效的连接请求报文段后，就误认为是 client 再次发出的一个新的连接请求。于是就向 client 发出确认报文段，同意建立连接。假设不采用 “三次握手”，那么只要 server 发出确认，新的连接就建立了。由于现在 client 并没有发出建立连接的请求，因此不会理睬 server 的确认，也不会向 server 发送数据。但 server 却以为新的运输连接已经建立，并一直等待 client 发来数据。这样，server 的很多资源就白白浪费掉了。采用 “三次握手” 的办法可以防止上述现象发生。例如刚才那种情况，client 不会向 server 的确认发出确认。server 由于收不到确认，就知道 client 并没有要求建立连接。”

如果你细读RFC793，也就是 TCP 的协议 RFC，你就会发现里面就讲到了为什么三次握手是必须的——TCP 需要 seq 序列号来做可靠重传或接收，而避免连接复用时无法分辨出 seq 是延迟或者是旧链接的 seq，因此需要三次握手来约定确定双方的 ISN（初始 seq 序列号）。

下面给出详细的 RFC 解读说明：（数据分组称为分段（Segment），国内通常用包来称呼）

---

我们首先要知道到一点就是， TCP 的可靠连接是靠 seq（ sequence numbers 序列号）来达成的。

A fundamental notion in the design is that every octet of data sent over a TCP connection has a sequence number. Since every octet is sequenced, each of them can be acknowledged. The acknowledgment mechanism employed is cumulative so that an acknowledgment of sequence number X indicates that all octets up to but not including X have been received.

TCP 设计中一个基本设定就是，通过TCP 连接发送的每一个包，都有一个sequence number。而因为每个包都是有序列号的，所以都能被确认收到这些包。

确认机制是累计的，所以一个对sequence number X 的确认，意味着 X 序列号之前(不包括 X) 包都是被确认接收到的。

The protocol places no restriction on a particular connection being used over and over again.
The problem that arises from this is -- "how does the TCP identify duplicate segments from previous incarnations of the connection?" This problem becomes apparent if the connection is being opened and closed in quick succession, or if the connection breaks with loss of memory and is then reestablished.

TCP 协议是不限制一个特定的连接（两端 socket 一样）被重复使用的。

所以这样就有一个问题：这条连接突然断开重连后，TCP 怎么样识别之前旧链接重发的包？——这就需要独一无二的 ISN（初始序列号）机制。

When new connections are created, an initial sequence number (ISN) generator is employed which selects a new 32 bit ISN. The generator is bound to a (possibly fictitious) 32 bit clock whose low order bit is incremented roughly every 4 microseconds. Thus, the ISN cycles approximately every 4.55 hours. Since we assume that segments will stay in the network no more than the Maximum Segment Lifetime (MSL) and that the MSL is less than 4.55 hours we can reasonably assume that ISN's will be unique.

当一个新连接建立时，初始序列号（ initial sequence number ISN）生成器会生成一个新的32位的 ISN。

这个生成器会用一个32位长的时钟，差不多4µs 增长一次，因此 ISN 会在大约 4.55 小时循环一次

（2^32位的计数器，需要2^32*4 µs才能自增完，除以1小时共有多少µs便可算出2^32*4 /(1*60*60*1000*1000)=4.772185884 ）

而一个段在网络中并不会比最大分段寿命（Maximum Segment Lifetime (MSL) ，默认使用2分钟）长，MSL 比4.55小时要短，所以我们可以认为 ISN 会是唯一的。

发送方与接收方都会有自己的 ISN （下面的例子中就是 X 与 Y）来做双方互发通信，具体的描述如下：

1) A --> B SYN my sequence number is X 2) A <-- B ACK your sequence number is X 3) A <-- B SYN my sequence number is Y 4) A --> B ACK your sequence number is Y

2与3都是 B 发送给 A，因此可以合并在一起，因此成为three way (or three message) handshake（其实翻译为三步握手，或者是三次通信握手更为准确）

因此最终可以得出，三次握手是必须的：

A three way handshake is necessary because sequence numbers are not tied to a global clock in the network, and TCPs may have different mechanisms for picking the ISN's. The receiver of the first SYN has no way of knowing whether the segment was an old delayed one or not, unless it remembers the last sequence number used on the connection (which is not always possible), and so it must ask the sender to verify this SYN. The three way handshake and the advantages of a clock-driven scheme are discussed in [3].

三次握手（A three way handshake）是必须的， 因为 sequence numbers（序列号）没有绑定到整个网络的全局时钟（全部统一使用一个时钟，就可以确定这个包是不是延迟到的）以及 TCPs 可能有不同的机制来选择 ISN（初始序列号）。

接收方接收到第一个 SYN 时，没有办法知道这个 SYN 是是否延迟了很久了，除非他有办法记住在这条连接中，最后接收到的那个sequence numbers（然而这不总是可行的）。

这句话的意思是：一个 seq 过来了，跟现在记住的 seq 不一样，我怎么知道他是上条延迟的，还是上上条延迟的呢？

所以，接收方一定需要跟发送方确认 SYN。

假设不确认 SYN 中的 SEQ，那么就只有：

1) A --> B SYN my sequence number is X 2) A <-- B ACK your sequence number is X SYN my sequence number is Y

只有B确认了收到了 A 的 SEQ， A 无法确认收到 B 的。也就是说，只有 A 发送给 B 的包都是可靠的， 而 B 发送给 A 的则不是，所以这不是可靠的连接。这种情况如果只需要 A 发送给 B ，B 无需回应，则可以不做三次握手。

---

所以，正确的类比应该是这样的：TCP 传递信息可以理解为美国与中国用货船来传货物，但因为一首轮船穿放不下，货物要分开一只只轮船来发货。

所以需要一个序列号来识别该货物是第几个，以便到达后将其拼接回原来的货物。

因为同一条航道（也就是 tcp连接）上，可能会有多批货物发送（复用 tcp 连接）。发货时，双方需要通知对方这个序列号是从哪里开始（init seq）的，这样才能辨识过来的是不是一个对的货物，以及能拼接成完整的货物。

货物运输拼接（tcp）最重要的是可靠性，如果没有用三次握手来确认双方都可以获得对方的 序列号（seq）的话，就无法知道当前航班（连接）中，对的货物序号是怎么样的了。

三次握手详细过程

             TCP A                                                TCP B ​   1.  CLOSED                                               LISTEN ​   2.  SYN-SENT    --> <SEQ=100><CTL=SYN>               --> SYN-RECEIVED ​   3.  ESTABLISHED <-- <SEQ=300><ACK=101><CTL=SYN,ACK>  <-- SYN-RECEIVED ​   4.  ESTABLISHED --> <SEQ=101><ACK=301><CTL=ACK>       --> ESTABLISHED ​   5.  ESTABLISHED --> <SEQ=101><ACK=301><CTL=ACK><DATA> --> ESTABLISHED ​           Basic 3-Way Handshake for Connection Synchronization ​                                 Figure 7.     

在上图

• 第二行中， A 发送了 SEQ 100，标志位是 SYN；
• 第三行，B 发回了 ACK 101 与 SEQ 300，标志位是 SYN 与 ACK（两个过程合并了）。注意，ACK 是101意味着，B 希望接收到 101序列号开始的数据段。
• 第四行，A 返回了空的数据，SEQ 101， ACK 301，标志位为 ACK。至此，双方的开始 SEQ （也就是 ISN）号100与300都被确认接收到了。
• 第五行，开始正式发送数据包，注意的是 ACK 依旧是第四行的301，因为没有需要 ACK 的 SYN 了（第四行已经 ACK 完）。

以上，4 最后这个确认的过程，是可以带上数据的。

         The principle reason for the three-way handshake is to prevent old   duplicate connection initiations from causing confusion.  To deal with   this, a special control message, reset, has been devised.  If the   receiving TCP is in a  non-synchronized state (i.e., SYN-SENT,   SYN-RECEIVED), it returns to LISTEN on receiving an acceptable reset.   If the TCP is in one of the synchronized states (ESTABLISHED,   FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK, TIME-WAIT), it   aborts the connection and informs its user.  We discuss this latter   case under "half-open" connections below.     

三次握手的原则设计是防止旧复用链接的初始化导致问题，为了解决此问题，我们设计了reset这个特别的控制信号来处理。

如果接收中的 TCP 在一个未同步状态如 SYN-SENT, SYN-RECEIVED，它会返回 reset 给对方。

如果 TCP 是同步状态中如(ESTABLISHED, FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK, TIME-WAIT)，他会终止此连接并通知用户。

看起来有点绕，我们举个图例看看：

            TCP A                                                TCP B ​   1.  CLOSED                                               LISTEN ​   2.  SYN-SENT    --> <SEQ=100><CTL=SYN>               ... ​   3.  (duplicate) ... <SEQ=90><CTL=SYN>               --> SYN-RECEIVED ​   4.  SYN-SENT    <-- <SEQ=300><ACK=91><CTL=SYN,ACK>  <-- SYN-RECEIVED ​   5.  SYN-SENT    --> <SEQ=91><CTL=RST>               --> LISTEN    ​   6.              ... <SEQ=100><CTL=SYN>               --> SYN-RECEIVED ​   7.  SYN-SENT    <-- <SEQ=400><ACK=101><CTL=SYN,ACK>  <-- SYN-RECEIVED ​   8.  ESTABLISHED --> <SEQ=101><ACK=401><CTL=ACK>      --> ESTABLISHED ​                     Recovery from Old Duplicate SYN     

这是 复用连接时，旧在途包发往新连接中的例子。

• 3中，一个旧的重复的 SYN到达 B。
• 4中， B分别不出是否旧的，照样子正常回包。
• 5中，A检测到 B 返回的ACK不正确，所以返回 RST(reset)
• 6中，B接收到 RST(reset)信号，于是变成 LISTEN 状态。
• 7中，新连接正常的 SYN终于到达了，三次握手正常进行。

这种是简化的情况，但是可以看出 TCP 是如何处理复用旧链接的包到达的。

---

ps：关于全局时钟的方法，我找到了一篇论文：http://mirrors.ustc.edu.cn/rfc/ien/ien193.pdf, 有兴趣的同学可以看看。

在这里要感谢 余晟以为 这个公众号的文章，里面一句提到rfc里有 三次握手是必须的原因，因此我顺势把rfc看了一下。

TCP连接建立过程中为什么需要“三次握手”

在谢希仁著《计算机网络》第四版中讲“三次握手”的目的是“为了防止已失效的连接请求报文段突然又传送到了服务端，因而产生错误”。在另一部经典的《计算机网络》一书中讲“三次握手”的目的是为了解决“网络中存在延迟的重复分组”的问题。这两种不用的表述其实阐明的是同一个问题。

谢希仁版《计算机网络》中的例子是这样的，“已失效的连接请求报文段”的产生在这样一种情况下：client发出的第一个连接请求报文段并没有丢失，而是在某个网络结点长时间的滞留了，以致延误到连接释放以后的某个时间才到达server。本来这是一个早已失效的报文段。但server收到此失效的连接请求报文段后，就误认为是client再次发出的一个新的连接请求。于是就向client发出确认报文段，同意建立连接。假设不采用“三次握手”，那么只要server发出确认，新的连接就建立了。由于现在client并没有发出建立连接的请求，因此不会理睬server的确认，也不会向server发送数据。但server却以为新的运输连接已经建立，并一直等待client发来数据。这样，server的很多资源就白白浪费掉了。采用“三次握手”的办法可以防止上述现象发生。例如刚才那种情况，client不会向server的确认发出确认。server由于收不到确认，就知道client并没有要求建立连接。”

这个例子很清晰的阐释了“三次握手”对于建立可靠连接的意义。

在Google Groups的

TopLanguage

中看到一帖讨论TCP“三次握手”觉得很有意思。贴主提出“

TCP建立连接为什么是三次握手？

”的问题，在众多回复中，有

一条回复

写道：“这个问题的本质是, 信道不可靠, 但是通信双发需要就某个问题达成一致. 而要解决这个问题, 无论你在消息中包含什么信息, 三次通信是理论上的最小值. 所以三次握手不是TCP本身的要求, 而是为了满足"在不可靠信道上可靠地传输信息"这一需求所导致的. 请注意这里的本质需求,信道不可靠, 数据传输要可靠. 三次达到了, 那后面你想接着握手也好, 发数据也好, 跟进行可靠信息传输的需求就没关系了. 因此,如果信道是可靠的, 即无论什么时候发出消息, 对方一定能收到, 或者你不关心是否要保证对方收到你的消息, 那就能像UDP那样直接发送消息就可以了.”。这可视为对“三次握手”目的的另一种解答思路。

后面一段话意思就是如果想确定双通道通畅，必须使用三个包的发送接收，也就是三次握手

http://www. cr173.com/exam/Cisco_17 954_1.html

其实是两次rtt，客户端和服务端各做一次hello，ack，共4步握手。只不过server向client ack和server向client发起hello两个步骤被优化为二合一了，于是变成“3次握手”。

类似的话题

• 

  TCP 为什么是三次握手，而不是两次或四次？

  

  TCP 的三次握手而不是两次或四次，是经过深思熟虑的、为了保证通信的可靠性和高效性而设计的。下面我将详细解释其中的原因：核心目标：建立一个可靠的、全双工的连接TCP 的目标是建立一个可靠的、面向连接的、全双工的通信通道。这意味着： 可靠性： 确保数据能够按顺序、不丢失、不重复地送达。 面向连.............
• 

  阿里云服务器tcp连接会猛然增到上万个是为什么

  

  .......
• 

  tcp 的可靠性到底指的是什么？

  

  TCP 的可靠性，简单来说，就是它能确保你发送的数据，能够准确无误地、按顺序地到达对方手中，并且中间不会丢失、不会错乱、不会重复。想象一下，你给朋友写信，希望他能收到你写的所有内容，而且每一句话的顺序都和你写的一模一样。TCP 在网络通信中扮演的就是那个尽职尽责的邮递员，只不过它的工作方式更像是一位.............
• 

  TCP 为什么没有基于 UDP 实现？

  

  TCP 之所以没有基于 UDP 实现，并非因为它“不能”，而是因为它“不应该”，或者说，它基于 UDP 来实现，会变得非常低效且失去意义。理解这一点，需要深入剖析 TCP 和 UDP 各自的设计哲学和核心功能。首先，我们得明确 TCP 和 UDP 这两个协议，它们都工作在传输层，负责在应用程序之间传.............
• 

  UDP 和 TCP 的 socket 分别一般用在什么地方？

  

  UDP 和 TCP 作为网络通信中两个最基础的传输层协议，它们的应用场景差异很大，选择哪种协议很大程度上取决于应用的需求。理解它们的区别，就像理解在城市里选择驾车还是骑自行车一样，各有优劣，适合不同的出行目的。先来聊聊 TCP：想象一下，你需要给一个非常重要的文件打包，然后通过邮局寄送。你希望这个文.............
• 

  基于UDP实现的可靠传输协议（比如uTP），与TCP协议相比有什么优缺点？

  

  要说基于 UDP 实现的可靠传输协议（比如 uTP），和我们熟悉的 TCP 比起来，那可真是各有千秋，优缺点都很鲜明。咱们掰开了揉碎了好好聊聊。 基于 UDP 的可靠传输协议（如 uTP） vs. TCP：一场优劣势大比拼首先得明确一点：TCP 是传输层协议里的“老大哥”，大家最熟悉，也是用得最多的.............
• 

  Linux Kernel 4.9 中的 BBR 算法与之前的 TCP 拥塞控制相比有什么优势？

  

  Linux Kernel 4.9 中引入的 BBR (Bottleneck Bandwidth and Roundtrip propagation time) 算法代表了 TCP 拥塞控制领域的一个重要进步。与之前广泛使用的算法（如 Cubic、Reno、NewReno）相比，BBR 具有以下显著优.............
• 

  TCP链接之间的网络物理断开了然后有连上，这个TCP链接是否断开？

  

  当TCP连接的网络物理链路发生断开，随后又重新连接，这个TCP连接本身是否被视为断开了，这是一个相当值得探究的问题。答案并非简单的“是”或“否”，而是要看我们从哪个角度去理解“断开”的含义。从TCP协议层面来看，可以认为这个连接在物理链路中断的那一刻，实际上是非正常终止了。TCP是一个基于连接的有状.............
• 

  如今只使用TCP协议开发 实时多人在线网络游戏 可行吗?

  

  如今，仅使用 TCP 协议来开发实时多人在线网络游戏是完全可行的，但需要付出更多的努力和权衡，并且在某些方面会存在固有的劣势。它不是一个理想的解决方案，但并非不可能。下面我将详细阐述其可行性、优势、劣势以及需要克服的挑战： TCP 协议简介及其特性在深入讨论之前，我们先回顾一下 TCP 的关键特性：.............
• 

  USB有可能整合TCP/IP协议吗？

  

  usb协议和tcp/ip协议是两个完全不同层面的东西，它们之间并没有直接的融合关系。不过，如果一定要说“整合”，我们可以从几个角度来理解这个问题，并且尽量不让它听起来像机器生成的：首先，我们要明白它们各自是什么东西： USB（通用串行总线）： 这个大家都很熟悉，就是你用来给手机充电、连接鼠标键盘.............
• 

  求推荐看tcp/ip源码的书籍？

  

  想深入理解 TCP/IP 的底层运作机制，从源码入手无疑是最直接有效的方式。市面上的书籍不少，但要说写得透彻、讲解得详尽，并且能引导你真正看懂源码的，我觉得有几本是绕不开的经典。我最近刚好温习过几本，结合自己的理解，跟你聊聊我推荐的书，希望能帮到你。一、 《TCP/IP Network Intern.............
• 

  最终的TCP传输层本质上还是一个需要顺序交付验证的管道，所以http2的管道化尝试意义有多大？

  

  最终的TCP传输层本质上还是一个需要顺序交付验证的管道，所以HTTP/2的管道化尝试意义有多大？ 这是一个值得深入探讨的问题。简单来说，HTTP/2的管道化确实在某些场景下带来了提升，但它并没有从根本上改变TCP固有的特性，也因此在实际应用中，其带来的“革命性”意义需要被放在一个更现实的框架下去审视.............
• 

  怎么解决TCP网络传输「粘包」问题？

  

  TCP 网络传输的“粘包”难题：如何做到滴水不漏在网络通信的世界里，TCP 协议扮演着至关重要的角色，它以其可靠、有序、面向连接的特性，为我们提供了稳定可靠的数据传输。然而，就像任何系统一样，TCP 并不是完美无缺的。当我们深入了解 TCP 的工作原理时，会发现一个常见的问题——“粘包”（Sausa.............
• 

  linux的TCP连接数量最大不能超过65535个，那服务器是如何应对百万千万的并发的？

  

  你提到的TCP连接数量最大不能超过65535个，这个数字其实有几种理解方式，而且对于服务器如何应对百万千万的并发，也并非仅仅是“TCP连接数”一个数字就能概括的。我们来掰开了揉碎了聊聊这其中的门道。首先，澄清一下“65535”的含义：当你听到“65535”这个数字在TCP连接中出现时，通常指的是：1.............
• 

  如何通俗地解释一下 TCP/UDP 协议和 HTTP、FTP、SMTP 等协议之间的区别？

  

  想象一下，你要寄一封信，或者打电话给朋友，这些日常沟通的方式，其实都离不开一些底层和上层的“规矩”和“方法”。在计算机网络里，TCP 和 UDP 就像是这两种最基本的通信方式，而 HTTP、FTP、SMTP 则是更具体的、用来做特定事情的“信件内容”或者“通话主题”。咱们先来说说 TCP。你可以把 .............
• 

  阿里云服务器tcp连接数1分钟内达到2000正常吗

  

  .......
• 

  阿里云服务器对 tcp 并发做了限制么

  

  .......
• 

  一台主机上只能保持最多 65535 个 TCP 连接吗？

  

  一台主机上最多能保持多少个 TCP 连接，理论上的最大值是 65535 个，但实际情况远比这个复杂，并且受多种因素影响，很多情况下远达不到这个理论值。下面我将详细解释这个问题：1. TCP 连接的本质：端口号一个 TCP 连接在客户端和服务器端都通过一个唯一的组合来标识： 客户端标识: IP 地.............
• 

  在阿里云服务器上,开端口使用Tcp+ssl自定协议,要备案吗?

  

  .......
• 

  阿里云服务器，如何设置对外通信 ip和端口（程序是tcp服务器，和不适用ASP的http服务器）

  

  .......