传输层协议（3）：TCP 连接（中）

5.2.4 全双工的TCP 连接

从某种意义上讲，本文前面的3节（5.2.1~5.2.3），笔者的目的都是为了讲述 TCP 连接是什么：

（1）从物理形式来说，TCP 连接就是两个 Host 进程内部相应的 TCB 数据结构实例。

（2）从逻辑形式来说，TCP 连接是人类的一个想象，或者一个比方，两个 Host 进程之间有那么1条（或多条）连接。

知道了 TCP 连接是什么以后，我们就不必再纠结 TCP 连接是真的“物理”存在还是存在于婶婶的脑海里，我们就接受这个名词，并基于这个名词继续往下探讨。

TCP 连接一个需要特别指出的特征是：它是全双工的。也就是说，TCP 连接创建以后，双向可以同时发送数据，如图5-29所示：

图5-29 TCP 连接全双工示意图

这个无须多解释，从具体实现来说，只要底下的3层（网络层、数据链路层、物理层）支持全双工，TCP 本身支持，那只是一句话的事情：当初 TCP 协议的设计者说它支持，它就支持，因为本身的实现难度并不大。

稍微需要解释的是，有的资料将 TCP的双方区分为“TCP Cliet、TCP Server”。需要强调的是，C-S（Client-Server）模式并不意味着就不能全双工，只是 C-S 模式总给人一种“一问一答”的感觉，也就说一方主动、一方被动。而全双工总给人一种双方是“对等体”的感觉。

TCP 不分攻与受

是的，“全双工”与“C-S 模式”两个概念的并存，只是感觉上好像有点不对，但是它们所表达的是不同的维度，两者并不矛盾。不过我们还是解释一下 TCP Client/TCP Server 的含义。笔者在图5-16中已经埋下了这两个名词的伏笔，这里为了阅读方便，再重新贴一下这个图，如图5-30所示：

图5-30 TCP 连接基本创建过程

图5-30中，将 Host A 标记为 TCP Client，将 Host B 标记为 TCP Server。其实，所谓的 Client/Server，指的是 TCP 连接创建过程中，谁是主动发起的一方：谁主动发起，谁就是 TCP Client；谁被动接受，谁就是 TCP Server。

如此一来，概念就很清晰了：

（1）TCP Client/Server，指的是 TCP 连接创建过程中，谁是主动方，谁是被动方。

（2）TCP 连接的全双工，指的是 TCP 数据传输过程中，双方可以同时传输数据。

两者所表达的场景是不同的。

图5-30中，同时还将 Host A 的初始状态标记为 CLOSED，Host B 的初始状态标记为 LISTEN。

Host A 的初始状态比较好理解，没有创建之前，连接是不存在的。这时候，将 HOST A 的状态标记为“NULL（空）”或者“CLOSED（关闭）”，都可以，其背后的含义都是 TCP 连接不存在。

而 HOST B 标记为“LISTEN（监听）”是什么含义呢？我们讲，TCP 连接的两端，其实是两个 Host 内部的某个进程——我们记为 P1、P2（P 是 Process 的缩写）——这意味着，TCP 连接创建的前提是 P1、P2 已经存在（已经启动起来）。

作为 TCP Client（假设是 P1）比较好理解，P1 是首先启动起来，然后再去主动创建连接，也就是发送 SYN 报文。P1 的 SYN 报文发送到 Host B 以后，作为 TCP Server 的Host B 的 TCP 模块（或者 TCP 内核）得确定相对应的进程（假设是 P2）存在，它才能与 TCP Client 完成三次握手的过程，从而建立起 TCP 连接。所以，P2 必须得先启动，在那里监听 TCP Client 的请求。这就是 Host B 的初始状态是“LISTEN”的含义。

但是，TCP 连接的创建并不绝对要求 C-S 模式，即一方主动请求，一方做好准备，监听到请求以后就与对方三次握手建立连接。TCP 连接的创建，也可以是双方同时发起。这个时候，就不存在 TCP Client/Server 的概念，如图5-31所示：

图5-31 同时创建 TCP 连接示意图

需要说明的是，“同时”创建 TCP 连接，这里的“同时”，并不是指时间上的绝对同时，而是指的的：（1）双发都发送连接请求报文（SYN 报文）；（2）在自己还没有收到对方发送的 SYN 报文时，自己已经发送给对方 SYN 报文了。这个对应到图5-31，就是 T1 时刻和 T2 时刻。T1 时刻，A 发送1个 SYN 报文（报文1）给 B。T2 时刻，B 还没有收到 A 发送过来的报文1，但是它也发送了1个 SYN 报文（报文2）给 A。

T3、T4 时刻，则比较简单，A 和 B 都分别收到了对方发送过来的 SYN 报文。B 收到 A 发送过来的 SYN 报文以后，我们看图5-31的 T5 时刻，它跟图5-30一样，B 就发送相应的 <SYN、ACK> 报文。

图5-31中，在 T4 时刻 A 收到了 B 发送过来的 SYN 报文，在 T6 时刻，A 收到了 B 发送过来的 <SYN、ACK>报文，然后再 T7 时刻发送了 ACK 报文。而在 T8 时刻，B 也收到了 A 发送过来的 ACK 报文。

在 T6 时刻，A 收到了 B 发送过来的 ACK 报文（连接创建请求的确认报文），所以 A 的状态就是 ESTABLISHED（表明 A 认为它的 TCP 连接已经创建）。同理，在 T8 时刻，B 也收到了 A 发送过来的 ACK 报文，所以 B 的状态也是 ESTABLISHED。

纵观以上文字和图5-31，虽然它比“5.2.1 TCP 连接的基本创建过程”复杂了一点，但是本质上，它仍然是“三次握手”——虽然从报文发送的角度，发了4次报文。

所以我们讲 TCP 的“三次握手”，说的是 TCP 连接创建的基本原理和基本流程，并不是说 TCP 连接的创建，绝对就是双方只发送了三次报文。

以笔者的经验，图5-31以及图下面对应的解释文字，并不复杂也不高深，但是它需要仔细阅读——对照着图，一字一字阅读，这样才好理解。一目十行，不太好懂。为了加深印象，笔者出一个题目，如图5-32所示：

图5-32 同时创建 TCP 连接（题目）

图5-32中，假设在 T5 时刻，是 A 向 B 发送报文，那么该时刻所发送的报文应该是什么？后续的报文是什么？

5.2.5 TCP 连接的关闭

TCP 连接，有创建，就有关闭。这不仅是为了逻辑上的闭环，也是为了资源上的可持续性。我们知道，TCP 连接，对于 Host 而言，就是其内部的一个 TCB 数据实例，更抽象地说就是 Host 内部的一块内存。如果只有创建（申请内存）没有关闭（释放内存），那么 Host早晚要内存耗尽，进而崩溃。

创建 TCP 连接，是为了要传输数据。那么自然地，数据传输完成，就可以关闭 TCP 连接，如图5-33所示：

图5-33 关闭TCP 连接

图5-33是接着图5-30的故事继续往下走：图5-30创建了连接以后，中间经过了数据传输，然后 A 发现它的数据传输完毕，就给 B 发送了1个关闭连接的请求，也就是图5-33中的报文1。所以，我们在图5-33中看到，A 和 B 的 SEQ 都相对于图5-30有所增加，这是因为中间这段时间，双方都互相发送了数据。

另外，从图5-30和图5-33可以看到，除了图5-30中的第1个请求连接创建的报文（A 发送给 B）以外，其他所有报文都打了 ACK 标记（ACK = 1），这既是 TCP 的规定，也是 TCP 保证可靠传输的机制。这一点，以前的小节已经做过讲述，后面的小节也还会继续简述。

本小节，为了讲述的方便和易于理解，就不再涉及端口号、SEQ、AKN 等几个字段，而专注于跟关闭连接最主要的几个字段。

图5-33，A 与 B 之间来来往往的4个报文，其基本含义，如表5-7所示：

表5-7 关闭 TCP 连接的报文的解释

报文	发送方	接收方	A 状态	B 状态
报文1	A	B	FIN-WAIT-1	CLOSE-WAIT
报文2	B	A	FIN-WAIT-2	CLOSE-WAIT
报文3	B	A	TIME-WAIT	LAST-ACK
报文4	A	B	TIME-WAIT	CLOSED
2MSL (不是报文)	——	——	CLOSED	CLOSED

表5-7中的 A 和 B 的状态，指的是 A、B 发送或接收报文以后的状态。比如第1行，A 的状态“FIN-WAIT-1”，指的是 A 发送了“报文1”以后的状态，而 B 的状态“CLOSE-WAIT”，指的是 B 接收了“报文1”以后的状态。

如前所述，当 A 没有数据要发送给 B 时，它向 B 发送了1个关闭连接的请求报文（报文1）——FIN 标记为1（FIN = 1）——FIN 是 Finis（终结）的缩写。

发送了报文1以后，A 进入 FIN-WAIT-1 状态，这有3层含义：

（1）A 不再发送数据

（2）但是它还可以接收数据

（3）A 的 TCP 连接还不能算关闭，它还要等待某件事情发送（接收某个报文）

当 B 接收到 A 发送过来的“报文1”时，发现是 A 发送过来的“请求关闭连接”的报文，此时 B 的状态变为“CLOSE-WAIT”。这也有3层含义：

（1）B 清楚，A 不会发送数据了，但是 A 还可以接收数据

（2）B 自己还可以发送数据（因为 A 还可以接收数据）

（3）B 自己也在等着连接关闭，虽然它还不知道到底何时能够关闭这个连接，所以 B 此时的状态叫作“CLOSE-WAIT”——不得不说，这个状态的名字比较形象，它表达了 B 的一种“渴望”，^_^

B 除了表达自己的“渴望”以外，也会立刻给 A 回以一个 ACK 报文（报文2），表示自己接受 A 关闭连接的请求。B 发送了“报文2”以后，它的状态仍然是“CLOSE-WAIT”——是的，它还在“渴望”。A 接收了“报文2”以后，它的状态变为“FIN-WAIT-2”——是的，它也还需要等待。

像这种，A 已经没有数据要发送（也不能发送）但是能接收数据，而 B 还能发送数据的情况，称为“half-open”连接（半开连接），此时 A 的状态等于“FIN-WAIT-1”或“FIN-WAIT-2”，B 的状态等于“CLOSE-WAIT”。

但是相思莫相负，生死随人愿。断井颓垣红开遍，原来春心酸楚由人恋。

唉......TCP 的世界哪有那么多感慨。过了一段时间以后，天遂人愿，B 也没有数据要发送给 A，那么它也会发送1个“请求关闭连接”的报文给 A（报文3）。

发送了“报文3”以后，B 的状态变为“LAST-ACK”。这个状态的名字取的也很形象，因为它知道，离 TCP 连接关闭的时间已经不远了，A 再也没有什么报文需要它来确认了——无论是否愿意，往事都不会再回来。

A 接收了“报文3”以后，它的状态变为“TIME-WAIT”，是的，它还需要等待——A 的关闭连接的一生，就是等待的一生，^_^。

除了要等待，A 在收到“报文3”以后，会马上给 B 回以1个 ACK 报文（报文4）：告诉B，它同意 B 的“关闭连接”的请求。

B 接到 A 发送过来的“报文4”以后，可没有任何客气，马上将自己的状态变为“CLOSED”，即关闭连接。关闭连接，字面上的意思就是将连接给关闭。实际上，根据前文描述，就是将该连接所对应的 TCB 内存块给删除。

这边厢，B 已经关闭了连接，而 A 还在那里痴痴地等，一直等待2个“MSL”时间，它才会将自己的状态设置为“CLOSED”，即关闭连接。

MSL，是 Max Segment Lifetime 的缩写，表达的是1个 TCP 报文在网络中所能存在的最大时间。因为 TCP 报文承载于 IP 报文，而 IP 报文头中又1个字段 TTL，TTL 最大值是255，1个 IP 报文在网络中最多经过255次路由器转发，就会被路由器给丢弃，所以对于1个 TCP 报文而言，存在1个 MSL。MSL 是一个经验数值，RFC 793 定义它等于“2分钟”，Linux 的实现，定义它是“30秒”。

A 为什么要等待2个“MSL”时间，很多资料都说有两个原因：（1）为了 B 能够优雅地关闭连接；（2）于 TCP 的 ISN 有关。

对于第2个原因，我们会放到后面的小节讲述。对于第1个原因，笔者以为，这很可能是一个以讹传讹的“传说”，反正鄙人没有在 RFC 793 里看到类似的描述。

所谓“B 能够优雅地关闭连接”，指的是：如果 A 发送被 B 的“报文4”，由于某种原因未能送达 B，那么 B（等了一段时间以后）还会继续发送“报文3”给 A，由于此时 A 还没有关闭（因为尚处于“TIME-WAIT”状态，A 还能继续给 B 回以1个“报文4”，这样的话，B 就能关闭它的连接了。

这种说法，有几点存疑：

（1）B 没有收到A 第1次发送的“报文4”，凭什么能保证会收到 A 第2次发送的“报文4”？

（2）如果 B 一直没有收到 A 发送的“报文4”，难道 B 就不关闭连接了吗？

（3）既然能够关闭，B 其实并不绝对需要接收 A 发送的“报文4”，这也就意味着，A 等待2个“MSL”时间，是为了 B——这种说法，毫无根据。

可是这样的怀疑，笔者不敢再继续下去。因为，按照前面怀疑的第3点，A 根本没有必要给 B 发送“报文4”，B 也不需要等待 A 发送的“报文4”，它发送完“报文3”以后，也没有必要将自己的状态设置为“LAST-ACK”，而是直接设置为“CLOSED”即可，也即发送完“报文3”以后，直接就可以将自己关闭。当然，这种猜测本身也有一定的问题。笔者会在后面的小节中——TCP 为什么需要三次握手四次挥手——继续讲述着问题。

无论如何，TCP 关于“关闭连接”的设计，定义了图5-33中的4个报文。这也就是著名的 TCP “四次挥手”！

与创建连接一样，关闭连接也存在双方“同时”关闭连接的场景。这只是“四次挥手”的一个变体，我们就不再详述，只是给出一个交互顺序图，如图5-34所示：

图5-34 同时关闭 TCP 连接

图5-34只是一种变体，伴随着 A、B 所发送/接收报文的时间的不同，还会有其他顺训图，正如图5-32给您留了一个思考图一样，为了能更好地掌握 TCP 连接的关闭，笔者也建议您针对这些变体做一些思考。

不过万变不离其宗，TCP 连接的关闭，其基本流程和本质，还是“四次挥手”。

再也回不去的从前

分手总在下雨天

雨水模糊了双眼

掩饰着泪流满面

5.2.6 TCP 连接的状态机

在前面的几个小节中，我们介绍了 TCP 连接的创建和关闭，本小节从 TCP 连接状态机的视角，对前述的内容做一个总结，如图5-35所示：

图5-35 TCP 连接的状态机

图5-35中，方框里的内容，表示的是 TCP 连接的“状态”，比如“CLOSED”、“ESTABLISHED”等等。每个带箭头的线条上（或者旁边）都加上了序号，为了讲述的方便。带箭头的线条连接着两个方框，这表示状态的变迁，比如第1个线条，表示状态从“CLOSED”变为“SYN SEND”。每个线条同时也对应着1对 <事件、响应>。

<事件、响应>用虚线分隔，虚线上方表示事件，虚线下方表示响应。

事件可能是 TCP 用户的动作，比如第1个线条所对应的事件就是“active OPEN”——这就是用户“active OPEN”了一个 TCP 连接。事件也可能是收到1个报文，比如第7个线条所对应的事件就是收到了1个“SYN”报文。

响应可能是 TCP 内核的动作，比如第2个线条所对应的事件就是“delete TCB”——TCP 内核删除相应的 TCB 内存块。响应也可能是发送1个报文，比如比如第7个线条所对应的响应就是发送了1个“SYN、ACK”报文。

图5-35中，有的“响应”写的是“x”，RFC 793 就是这么写的，x 所对应的具体含义，下文会解释。

针对图5-35更全面的解释，我们分步骤、用多个表来解释：（注意，表内容的顺序，没有完全按照线条的顺序）

表5-8 TCP 连接状态机的解释（1）

线条	原状态	事件	响应	新状态
1	CLOSED	active OPEN	create TCB send SYN	SYN SEND
2	SYN SEND	CLOSE	delete TCB	CLOSED
3	CLOSED	passive OPEN	create TCB	LISTEN
4	LISTEN	CLOSE	delete TCB	CLOSED

TCP 连接的状态机，从“CLOSED”开始。所谓 CLOSED，其实就是 TCP 连接不存在的意思。既然不存在，那就得首先创建连接。

创建连接有两种方式，一种是“active OPEN”，另一种是“passive OPEN”。这两种创建方式，如果用代码（伪码）来表示，更容易表达和理解：

#创建1个 server 端 socket

socket_server = socket();

#绑定 IP 地址和端口号

socket_server.bind(ip1, port1);

#创建1个 client 端 socket

socket_client = socket();

#绑定 IP 地址和端口号。一般来说，client socket 的端口号，

#不需要用户制定，TCP 内核会自动分配端口号

socket_client.bind(ip2, port2);

#对于 server 端 socket 来说，它尽管监听 client 端的连接请求就可以了

socket_server.listen();

#对于 client 端 socket 来说，它是主动向 server 端发起连接请求

socket_client.connect(socket_server)

伪码中的 client 端和 server 端的概念，我们在“5.2.4节全双工的 TCP 连接”中介绍过：谁主动发起 TCP 连接的请求，谁就是 TCP Client，而另一方就是 TCP Server。

结合伪码，我们就很容易知道，所谓“active OPEN”，其实就是创建1个 TCP Client 的连接（表面上是创建1个 socket，背后还需要创建 TCB 内存块），“passive OPEN”就是创建1个 TCP Server 端的连接（表面上是创建1个 socket，背后还需要创建 TCB 内存块）。

对于 TCP Client 来说，它还需要主动发送连接创建请求报文，所以我们在第1条线条的响应中还看到了“send SYN”——发送 SYN 报文。而对于 TCP Sever 来说，它只需要监听就可以了。

无论是 TCP Client 还是 TCP Server，此时它们还没有经过三次握手，两者之间的“连接”还没有对上，所以此时它们如果要关闭连接，则比较简单（不需要像“5.2.5 TCP 连接的关闭”所介绍的那样进行四次挥手），只需要直接“CLOSE”即可——而 CLOSE 的背后，就是删除对应的 TCB 内存块。

以上的解释，对应的就是表5-8。我们继续往下分析，如表5-9所示：

表5-9 TCP 连接状态机的解释（2）

线条	原状态	事件	响应	新状态
7	LISTEN	receive SYN	send SYN, ACK	SYN RECEIVED
8	SYN RECEIVED	receive ACK of SYN	x	ESTABLISHED
9	SYN SEND	receive SYN, ACK	send ACK	ESTABLISHED
5	LISTEN	SEND	send SYN	SYN SEND
6	SYN SEND	receive SYN	send SYN	SYN RECEIVED

表5-9中的“7、8、9”表达的就是著名的 TCP 三次握手。其中第8个线条中的响应，RFC 793标识的是“x”，表面上看，那什么都不用做，只是把状态迁移到“ESTABLISHED”即可。实际上，Host 内部还需要要创建 socket pair <s1, s2>，用以标识一对 TCP 连接。同时对于线条9，虽然 RFC 793 只标识了它的响应为“send ACK”，但是它的背后也是会创建 socket pair <s1, s2>。

线条5，表面上看是 TCP 在调皮：因为1个处于 LISTEN 状态的 TCP，它的标准动作是除了监听啥也不做，静待其他 TCP 的连接创建请求的到来——岁月静好，静待幸福来敲门。但是，它竟然不按常理出牌，主动“send SYN”：主动发送了1个连接创建请求报文。

线条6，表面上看也是不按常理出牌。因为处于“SEND SYN”状态的 TCP，其标准事件是“receive SYN, ACK”，而不是“receive SYN”。

实际上结合“5、6”，再结合“7、8、9”就会发现，它们所表达的其实是“同时创建 TCP 连接”的场景。

表5-8、5-9表达了 TCP连接从无到有的创建过程，我们忽略掉中间的数据传输过程，那么剩下的就是数据传输结束以后的连接关闭过程，如表5-10所示：

表5-10 TCP 连接状态机的解释（3）

线条	原状态	事件	响应	新状态
10	ESTABLISHED	CLOSE	send FIN	FIN-WAIT-1
11	FIN-WAIT-1	receive ACK of FIN	x	FIN-WAIT-2
12	FIN-WAIT-2	receive FIN	send ACK	TIME-WAIT
13	TIME-WAIT	Timeout = 2MSL	delete TCB	CLOSED
14	ESTABLISHED	receive FIN	send ACK	CLOSE-WAIT
15	CLOSE-WAIT	CLOSE	send FIN	LAST-ACK
16	LAST-ACK	receive ACK of FIN	delete TCB	CLOSED

表5-10表达的是 TCP 关闭连接的经典的“四次挥手”过程。表面上看线条11，什么都不用做，只需要等待对端发送“连接关闭请求”报文。实际上线条11、线条12，包括其他多个线条，其背后都需要创建1个定时器，因为总不能再那傻等。关于定时器、定时器超时等处理，我们放在下一小节讲述。

除了经典的“四次挥手”，TCP 还可以同时关闭连接，如表5-11所示：

表5-11 TCP 连接状态机的解释（4）

线条	原状态	事件	响应	新状态
18	FIN-WAIT-1	receive FIN	send ACK	CLOSING
19	CLOSING	receive ACK of FIN	x	TIME-WAIT

线条18，表面上看也是不按常理出牌，实际上“18、19”，在加上“13”，表达的就是“同时关闭 TCP 连接”的场景。

线条19中的响应“x”，应该是真不需要做什么，除了启动 2MSL 定时器。

无论是“四次挥手”，还是同时关闭（说明：本质上还是四次挥手），表5-10，5-11 表达的都是 TCP 连接创建好了以后（双方的状态都是“ESTABLISHED”）再关闭的场景。线条17表达的则是连接创建 OK 之前，就直接关闭。由于状态“SYN RECEIVED”表示的是“已经接到对端发送过来的连接请求报文”，所以不像线条2和线条4，线条17还是采取了相对“优雅”的动作：发送 FIN 报文（连接关闭请求报文）。

至此，图5-35所表达的TCP 连接的状态机，介绍完毕。但是，图5-35所表达的仅仅是正常流程，那么对于异常情形，TCP 会怎么处理呢？

传输层协议（3）：TCP 连接（中）相关推荐

TCP/IP传输层协议实现 - TCP连接的建立与终止(lwip)
1.lwip tcp相关数据结构 1.1.tcp报文格式 <TCP-IP详解卷 1:协议>TCP包首部结构如下: 1.2.lwip tcp数据结构 tcp相关数据结构如下,tcp_pcb_ ...
传输层协议（TCP/UDP）介绍
一,TCP/IP协议族的传输层协议概况: 1,TCP:传输控制协议 2,UDP:用户数据报协议二,TCP/UDP协议详解: 1,TCP a.TCP是面向连接的,可靠的进程到进程通信的协议 ...
Linux网络编程（传输层协议）—tcp三次握手/四次挥手
传输层协议:负责应用程序之间数据传输-TCP/UDP UDP协议: 16位源端-对端端口:用于描述识别通信两端进程 16位数据报长度:能够存储最大数字 65535,(udp报文总大小不超过64k) 1 ...
OSI七层协议与TCP连接
概述为了追求效率,我们写代码,不可能去关注底层知识,但往往到出了问题,或者性能调优.我们就会速手无策,仔细为自己查缺补漏,总结知识点. 网络协议互联网的本质就是一系列的网络协议,让不同计算机能够互 ...
传输层协议之TCP协议详解
传输层重点协议:UDP和TCP. 作用:负责数据能够从发送端传输到接收端.(在进行网络编程时,我们会使用到socket,然而一旦调用socket就进入到了传输层的范畴内) 前面我们已经讲过UDP协议了 ...
TCP/IP传输层协议实现 - TCP的超时与重传(lwip)
(参考<TCP-IP详解卷 1:协议> 第21章 TCP的超时与重传) 1.往返时间测量(RTT) 1.1.分组交换和RTT测量示例 <TCP-IP详解卷 1:协议>中分组交换 ...
TCP/IP传输层协议实现 - TCP接收窗口/发送窗口/通告窗口(lwip)
1.tcp通告窗口/接收窗口/发送窗口接收端有一个接收窗口大小,接收端只能接收这么多数据,接收窗口的数据需要被上层接收后才释放更大接收空间,才可以接收更多数据:接收窗口之前的数据已经被接收,再次接收 ...
TCP/IP传输层协议实现 - TCP的坚持定时器(lwip)
(参考<TCP-IP详解卷 1:协议>"第22章 TCP的坚持定时器") 1.糊涂窗口综合症 <TCP-IP详解卷 1:协议>"22.3 糊涂窗口 ...
4-1：TCP协议之传输层的作用及传输层协议TCP和UDP
文章目录一:传输层的定义二:通信处理三:传输层协议四:TCP协议的可靠和性能一:传输层的定义前面说过,IP首部有一个协议字段用于标识网络层(IP)的上一层采用哪一种传输层协议.根据这个字段 ...
网络中的七层协议与TCP/IP五层模型
socket(套接字)是通信的基石,是支持TCP/IP协议的网络通信的基本操作单元,包含进行网络通信必须的五种信息:连接使用的协议,本地主机的IP地址,本地进程的协议端口,远地主机的IP地址,远地进程 ...

传输层协议（3）：TCP 连接（中）

传输层协议（3）：TCP 连接（中）相关推荐

最新文章

热门文章