1. 传输层的协议
1.1 TCP (传输控制协议) - rfc793
连接模式的传输。
保证按顺序传送数据包。
流量控制、错误检测和在数据包丢失时的重传。
用于需要可靠传输的应用，如网络（HTTP/HTTPS）、电子邮件（SMTP, IMAP, POP3）和文件传输（FTP）。
1.2 UDP (用户数据报协议) - rfc768
数据报模式。
没有交付、顺序或错误检测的保证。
用于速度比可靠性更重要的应用，如视频流或在线游戏。
1.3 DCCP (数据报拥塞控制协议) - rfc4340
为流媒体和需要拥塞控制但不一定需要可靠交付的应用而设计。
结合了TCP和UDP的特点。
1.4 SCTP (流控制传输协议) - rfc4960
支持传输多个消息流。
可以抵抗网络错误，如从一个路径切换到另一个路径。
主要用于电信网络中的信令传输。
1.5 MPTCP (多路径TCP) - rfc6824
是TCP的一个扩展，允许使用多个路径在两个端点之间传输数据。
提高了弹性和带宽利用率。
1.6 QUIC
基于UDP。
与TCP+TLS相比，设计目的是减少延迟。
集成的多路复用和快速的加密协商。
最初由Google开发，目前正在由IETF进行标准化。具体的RFC引用将取决于这一标准化完成的日期。
2. TCP（传输控制协议）
2.1 TCP报文段的结构
TCP报文段是TCP连接中传输的数据单元，包含以下主要部分：
2.1.1 源端口（Source Port）和目的端口（Destination Port）
这两个字段指定了发送和接收数据的端口号，用于标识发送和接收的应用程序。
2.1.2 序列号（Numéro de séquence）
用于确保数据传输的顺序性，并为可靠传输提供必要的信息。
2.1.3 确认应答号（Acquittement）
一个序列号，确认收到的数据，用于实现TCP的可靠性。
2.1.4 数据偏移（Header Length）
指示TCP报头的长度，因为TCP报头可以包含一个可变数量的选项。
2.1.5 保留（Resv）
保留字段，用于未来的使用，目前应该设置为0。
2.1.6 控制位（Bits de contrôle）
一组标志位，包括URG（紧急指针有效）, ACK（确认字段有效）, PSH（提示接收方尽快将这个报文段交给应用层）, RST（重置连接）, SYN（同步序列编号，用于建立连接）, FIN（释放连接）。这些位用于控制发送者和接收者之间的TCP连接的行为。以下是每个位的详细解释：
2.1.6.1 ECE (显式拥塞通知回显) - rfc 3168
当TCP实体接收到带有此位为1的段时，它应该减少其传输速率。这是网络拥塞的指示。
2.1.6.2 CWR (拥塞窗口已减少) - rfc 3168
这是对接收到ECE位的响应。它表示已经考虑到了降低速率的请求。
2.1.6.3 URG
表示TCP头中的“紧急指针”字段是有意义的。这意味着段中的某些数据被视为紧急。
2.1.6.4 ACK
表示TCP头中的“确认号”字段是有意义的。这是确认数据已被接收的标志。
2.1.6.5 PSH (推送)
表示数据应立即传递给上层，而不等待缓冲区满。
2.1.6.6 RST (重置)
表示连接应被重置。这通常是对连接中的错误或问题的响应。这是一个重要的控制位，用于处理异常情况：
2.1.6.6.1 RST控制位的用途
当一个TCP实体与另一个远程TCP实体连接时，RST位用于警告存在问题。
2.1.6.6.2 正常的应用程序终止
正常结束的应用程序会在使用的TCP端口上进行关闭（通常是一个套接字）。这通过交换设置了FIN位的段来实现，从而断开连接。
2.1.6.6.3 异常的应用程序终止
如果应用程序突然终止而没有关闭连接，与其关联的TCP实体会向另一端发送设置了RST位的段。这样，另一端就被通知连接已经终止。
简而言之，RST位是TCP协议中的一个机制，用于在发生异常或错误时快速终止连接。当一个端点收到设置了RST位的段时，它知道远程端点已经重置连接，因此它也应该立即终止连接。
2.1.6.7 SYN (同步)
用于建立TCP连接。它在发送者和接收者之间同步序列号。
2.1.6.8 FIN (完成)
表示发送者已完成数据发送并希望终止连接。
这些控制位对于TCP的正确和高效运作至关重要。它们允许网络上的两个实体进行可靠和有序的通信。
2.1.7 窗口大小
用于流量控制，它指定了发送方能发送的、开始于确认字段中指明的序列号的、不需要接收方确认的数据量。
2.1.8 校验和
用于检测报文段在传输过程中的任何变化，以确保数据的完整性。
2.1.9 紧急指针
仅在URG控制位被设置时有效，它指出了报文段中紧急数据的结束位置。
2.1.10 选项
如果有的话，可以有多个选项，每个选项都是32位的倍数。
2.1.11 数据
这部分是传输的应用数据。
TCP通过这种复杂的报文段结构，实现了一种可靠的、面向连接的、流控制的传输层协议，它确保了数据可靠传输和正确顺序到达目的地。
2.2 例子
0: 0800 2074 ef05 0800 0914 18e7 0800 4500
16: 0028 8954 0000 4006 db07 c02c 4b13 c02c
32: 4b08 1770 fdbe 0162 6e86 8e21 a873 5010 /* 0001 0000 */
48: 2210 bba3 0000 023a b3a1 1829您提供了一个数据包的十六进制表示，并指出了其中的TCP ACK位为1。
让我们分析这个数据包：
首先，我们可以看到这是一个IP数据包，因为在偏移量为9的位置（第二行的第三个字节）的值为0x06，这表示该数据包使用的是TCP协议（在IP头部中，协议字段的值为6表示TCP）。
TCP头部开始于偏移量为20的位置，因为标准的IPv4头部长度为20字节。在TCP头部中，控制位位于偏移量为13的位置（从TCP头部开始计算）。在您提供的数据中，这个位置的值为0x50，它的二进制表示为`0101 0000`。
从这个二进制值中，我们可以看到ACK位确实为1（从右数第五位），而其他的控制位（CWR, ECE, URG, PSH, RST, SYN, FIN）都为0。
因此，您的描述是正确的：这个TCP段的ACK位为1。
2.3 紧急指针
“紧急数据”或称为“带外数据”（Out of Band，OOB）的概念
这是TCP协议中的一个特性，允许发送方标记某些数据为“紧急”，以便接收方可以优先处理它们
2.3.1 紧急数据
有时被称为“带外数据”或Out of Band (OOB)。
2.3.2 优先处理
这些数据需要被接收层优先处理。
2.3.3 正常传输
尽管这些数据被标记为“紧急”，但它们仍然在正常的数据流中传输并遵循正常的路径。IP层对这些数据不敏感，只有在两端（发送端和接收端）这些数据的“紧急”性质才有意义。
2.3.4 随机性
对于目标应用程序，这些数据的到达具有随机性。
2.3.5 数据流中的读取
应用程序不会在正常的数据流中读取这些数据。
2.3.6 处理紧急数据
任何希望接受此类数据的应用程序都必须通知系统，以便系统可以发送一个中断（或称为软件信号）给它，这样应用程序就可以优先处理这些数据。应用程序必须预先设定一个特殊的处理程序来读取这些数据。
2.3.7 语义不明确
RFC6093建议新的应用程序不再使用这一特性，因为它的语义定义不明确。
总的来说，尽管TCP提供了“紧急数据”或“带外数据”的功能，但由于其语义不明确和其他问题，它在现代应用中的使用已经变得不那么普遍。
2.4 TCP（传输控制协议）的“面向连接”的特性
2.4.1 TCP连接
TCP是一个面向连接的协议。
2.4.2 点对点的关系
TCP连接是在两个端点之间建立的点对点关系。
2.4.3 对路由器的透明性
TCP连接对路由器通常是透明的，除非路由器实施了过滤或QoS（服务质量）机制。
2.4.4 端点上的上下文特征
TCP连接在端点机器上由一个上下文特征，该上下文包括本地和远程的IP地址以及本地和远程的端口号。
简而言之，TCP是一个面向连接的协议，这意味着在数据传输之前，两个通信实体必须首先建立一个连接。这个连接是由端点上的上下文（如IP地址和端口号）定义的，并且对大多数中间设备（如路由器）是透明的。
2.5 TCP（传输控制协议）的“连接”概念以及相关特性
2.5.1 建立连接
连接是通过初始数据包交换建立的，这个过程称为“三次握手”（three way handshake）。
这个过程包含以下步骤：
2.5.1.1 SYN（同步）
客户端发送一个带有序列号X的SYN包到服务器以请求建立连接。
2.5.1.2 SYN-ACK（同步确认）
服务器收到SYN包后，发送一个带有自己序列号Y和确认号X+1的SYN-ACK包作为响应，确认号X+1表示服务器已经收到客户端的SYN包，并期望收到序列号为X+1的下一个数据包。
2.5.1.3 ACK（确认）
客户端收到SYN-ACK包后，发送一个带有确认号Y+1的ACK包到服务器，表示客户端已经收到服务器的SYN-ACK包，并期望收到序列号为Y+1的下一个数据包。
完成这三步后，TCP连接建立，客户端和服务器开始数据传输。这个三次握手过程确保了双方都知道彼此已经准备好进行通信，并且同步了序列号，这对于TCP提供的可靠连接至关重要。
2.5.2 连接的定义
这并不是“连接”这个词的严格意义上的连接，因为在网络中没有建立虚拟路径。TCP段是通过IP传输的，而IP是一个面向数据报的协议。
2.5.3 TCP连接的表示
TCP连接在端点机器（客户端和服务器）上表示为一个保存在内存中的上下文。这个上下文是一个五元组，包括：[协议, 本地端口, 远程端口, 本地IP地址, 远程IP地址]。
简而言之，尽管TCP是一个“面向连接”的协议，但这并不意味着在网络中有一个物理或虚拟的持续连接。相反，这个“连接”是通过在通信的两端维护上下文信息来实现的，这些上下文信息包括端口号和IP地址等。
2.5.4 无数据交换
如果连接的应用程序没有数据要交换，相应的TCP实体不会发送任何段，因此不会有任何流量。
2.5.5 警告段
可以设置TCP的一个选项，使得TCP实体每两小时发送一个警告段（这些段不包含实际的数据，因为没有数据要发送）。
2.5.6 无响应的远程TCP实体
如果远程TCP实体没有响应警告段，这可能意味着关联的应用程序已经在没有通知的情况下终止，或者机器已经停止运行。当本地应用程序下次从TCP端口读取时，它会被通知。
这些特性突显了TCP的可靠性和健壮性。即使在长时间没有数据交换的情况下，TCP仍然提供了机制来检测连接的状态，并确保应用程序在连接中断时得到通知。
2.5.7 TCP中的“主动连接”和“被动连接”的概念
2.5.7.1 被动连接
这不是一个真正的连接，而是一个由服务器应用程序打开的TCP访问点。创建的TCP上下文等待来自客户端的连接请求。
2.5.7.2 主动连接
这是一个真正的连接，由客户端模式的应用程序初始化。
在TCP的上下文中，当我们谈论“被动连接”时，我们通常指的是服务器正在监听并等待来自客户端的连接请求。而“主动连接”则是指客户端主动发起的连接请求。
例如，当您在浏览器中输入一个网址并按下Enter键时，您的浏览器（作为客户端）会主动发起一个TCP连接到该网站的服务器。而该服务器在其端会有一个被动连接，等待这样的请求。
2.6 TCP（传输控制协议）的状态机
TCP状态机描述了一个TCP连接在其生命周期内可能经历的不同状态以及在收到不同类型的TCP报文时会发生的状态转换。这些状态包括：
Closed：没有活跃的连接，也没有正在等待建立的连接。
Listen：服务器端的TCP正在等待来自客户端的连接请求。
SYN Sent：客户端已发送连接请求（SYN报文），等待服务器确认。
SYN Received：服务器已收到连接请求并响应了连接请求，等待客户端确认。
Established：连接已建立，数据可以开始传输。
Fin Wait 1：发起连接终止的一方等待对方的连接终止请求的确认。
Fin Wait 2：发起连接终止的一方已收到对方的确认，并等待对方的连接终止请求。
Close Wait：一方已收到对方的连接终止请求，等待本地用户的连接终止请求。
Closing：双方都等待对方确认其连接终止请求。
Last Ack：一方等待对方对其连接终止请求的最终确认。
Time Wait：确保对方已经接收到连接终止请求的确认后，等待足够的时间以确保对方接收到最终的ACK。
Closed：连接完全终止，两边都不再有连接。
TCP的状态机确保了TCP连接的可靠地建立和终止，是TCP协议可靠性和顺序性保证的关键部分。每一个状态的转换都是根据接收到的特定TCP报文来触发的。
2.7 计算机网络中端口的概念
在网络通信中，端口是数字标识符，它使得计算机上运行的不同应用程序能够通过网络进行通信。每个使用TCP/IP协议的应用程序都将其通信关联到一个或多个端口。
有两台机器（机器M和机器N），每台机器都运行着两个应用程序（例如，文件传输和邮件应用）。每个应用程序通过其特定的端口与TCP协议层进行通信。TCP协议层再与IP协议层通信，IP协议层负责将数据发送到网络。
端口可以被视为计算机上的虚拟通信终点，它们通常由操作系统管理。端口号范围从0到65535，其中特定的端口号被指定为“知名端口”，用于特定的服务（例如，HTTP通常使用端口80，而电子邮件的SMTP服务通常使用端口25）。当数据包到达一个机器时，IP协议层将其传递给TCP协议层，TCP协议层再根据数据包头部的端口信息将数据包送到正确的应用程序。
2.8 在计算机网络中连接的识别方法
在TCP/IP网络中，一个“连接”是由多个元素唯一确定的，包括：
协议类型（TCP或UDP）
源IP地址和源端口号
目的IP地址和目的端口号
两个客户端机器（机器A和机器B）以及它们连接到的服务器机器S，服务器上有两个服务（服务1和服务2）。每个客户端通过其源端口（端口Px）和服务器的目的端口（端口S1或S2）建立连接。图中说明了如何使用这些参数来确保网络中的连接是唯一可识别的，即使是在多个连接共享相同的服务端端口的情况下。
这种连接的唯一性是通过四元组来实现的，四元组包括源IP地址、源端口、目的IP地址和目的端口。使用这些信息，网络中的每个连接都可以被精确识别，从而允许数据准确地发送和接收。
2.9 TCP头部中的选项字段及其特性
2.9.1 TCP选项的特性
在TCP/IP协议中，TCP头部的"偏移量"字段用来指示TCP头部有多大。这里的一些关键点解释如下：
2.9.1.1 偏移量字段
TCP头部中有一个4位的"偏移量"字段，它表明了头部有多少个32位的字。由于这个字段是4位的，所以它的最大值是1111二进制，即15十进制。这意味着TCP头部最长可以是15个32位字，即60字节。
头部最小长度：TCP协议规定，TCP头部的最小长度是5个32位的字，即20字节。这是因为TCP头部必须至少包含基础的控制信息，如源端口、目的端口、序列号、确认号等。
2.9.1.2 选项字段长度
既然TCP头部的最大长度是60字节（15个32位字），而基础头部是20字节（5个32位字），那么选项字段的最大长度就是60 - 20 = 40字节，即10个32位字。
这个选项字段允许TCP头部被扩展以包含额外的信息，如最大报文段大小（MSS）、窗口缩放因子、选择性确认（SACK）等，这些都是TCP协议高级特性的一部分。简单来说，偏移量字段告诉我们TCP头部除了固定的20字节基础部分外，还可以有多少额外的空间用于包含这些选项。
2.9.1.3 标准选项
2.9.1.3.1 mss（最大段大小）
该选项允许协商TCP段的最大大小，以避免昂贵的分段操作。此选项在连接时使用。长度为4个字节。
2.9.1.3.2 无操作（NOP）
这是一个空选项，用于确保下一个选项从32位字的开始位置对齐。如果需要，可以连续使用多个NOP。长度为1个字节。
2.9.1.3.3 选项列表结束
该选项确保选项的结束位置与32位字对齐。长度为1个字节。
这些选项提供了TCP头部的灵活性和扩展性，允许在连接建立时进行各种参数的协商和调整。
两种高级功能的选项，窗口缩放因子和时间戳，它们都是为了提高网络通信效率而设计的。
2.9.1.3.4.窗口缩放因子（Window Scale）
在TCP连接中，窗口大小（Window Size）字段通常用于控制发送方可以发送的数据量，而不需要等待接收方的确认，这是为了实现流量控制。在原始的TCP协议中，这个字段是16位的，因此最大可以表示的窗口大小是 2^{16}-1 字节。
但是对于高速网络或者延迟较高的网络（如卫星通信），这个大小可能不足以有效利用可用的带宽。为了解决这个限制，RFC 1323 引入了窗口缩放选项，它允许窗口大小字段的值乘以2^n（其中n是窗口缩放因子，最高可到14），从而允许更大范围内的窗口大小，增加了流量控制的灵活性。
2.9.1.3.5 数据时间戳（Timestamps）
时间戳选项用于记录发送和确认数据包的时间。这个选项包括两个值：一个是发送时间戳，另一个是最近一次收到的确认消息的时间戳。
当数据发送者发送数据时，它会在时间戳选项的第一个字段中放入当前的时间戳。当接收者回复确认时，它会在确认包的时间戳选项的第二个字段中包含它最后一次收到数据包时的时间戳。
这样，发送者收到确认时，就可以通过比较自己的当前时间戳和确认包中的时间戳来计算往返时间（RTT）。这个计算对于动态调整数据发送速率和检测网络拥堵非常有用。
简单来说，窗口缩放因子用来增加TCP流量控制的窗口大小，而时间戳用来计算数据包的往返时间，这两个功能都是为了提升在不同网络条件下TCP协议的性能。
2.9.1.3.6 选择性确认的协商（rfc 2018）
TCP选项中的"选择性确认"（Selective Acknowledgment，简称SACK），是由RFC 2018定义的一种机制，它允许在数据传输过程中更有效地处理丢包情况。
选择性确认的协商：当建立TCP连接时，通信双方可以通过TCP头部中的选项字段来协商是否使用SACK。如果双方都支持并同意使用SACK，那么它们可以在传输过程中使用此功能。
选择性确认的工作原理：在标准的TCP确认中，如果数据包丢失，接收方只能确认它顺序接收的最后一个数据包。发送方必须从那个点开始重传丢失的数据包及其后的所有数据包，即使有些数据包可能已经被接收方正确接收。
SACK则允许接收方明确告知发送方哪些数据已经被成功接收。这是通过在确认（ACK）报文中包含已成功接收的数据块的信息来实现的。因此，发送方只需要重传那些实际上丢失的数据段，而不是所有后续的数据。
选择性确认优化了TCP的错误恢复过程，特别是在网络条件不佳或丢包率较高的环境中，它可以显著提高数据传输的效率。通过只重传丢失的数据，而不是连续的数据序列，它减少了不必要的网络流量和可能的拥塞，从而提高了TCP连接的整体性能。
2.10 TCP数据包序列的捕获示例
这是在Web请求的开始时使用`tcpdump`工具捕获的。这个序列显示了TCP三次握手的过程，以及随后的数据传输。以下是对这个捕获的简要解释：
rfc-1323 et rfc 2018 (relevé avec tcpdump lors d’un début de requête web)
linux1.1082 > 206.132.41.203.www: S 2047350264:2047350264(0) win 16060 <mss
1460,sackOK,timestamp 43244276>
206.132.41.203.www > linux1.1082: S 2319802134:2319802134(0) ack 2047350265 win
32120 <mss 1460, sackOK, timestamp 190973015>
linux1.1082 > 206.132.41.203.www: . ack 2319802135 win 16060 <nop,nop,timestamp
43244311 190973015>
linux1.1082 > 206.132.41.203.www: P 2047350265:2047350896(631) ack 2319802135 win
16060 <nop, nop, timestamp 43244311 190973015>
206.132.41.203.www > linux1.1082: . ack 2047350896 win 31856 <nop, nop, timestamp
190973051 43244311>)
206.132.41.203.www > linux1.1082: P 2319802135:2319803583(1448) ack 2047350896 win
31856 <nop, nop, timestamp 190973063 43244311>
linux1.1082 > 206.132.41.203.www: . ack 2319803583 win 14612 <nop,nop,timestamp
43244367 190973063>
206.132.41.203.www > linux1.1082: P 2319803583:2319805031(1448) ack 2047350896 win
31856 <nop, nop, timestamp 190973063 43244311>2.10.1 三次握手
`linux1.1082 > 206.132.41.203.www: S ...`: 这是三次握手的第一步，其中`linux1`发送一个SYN段到`206.132.41.203`的www端口。它还提供了一些TCP选项，如MSS（最大段大小）、SACK（选择性确认）和时间戳。
`206.132.41.203.www > linux1.1082: S ...`: 这是三次握手的第二步，`206.132.41.203`回应了一个SYN-ACK段。
`linux1.1082 > 206.132.41.203.www: . ...`: 这是三次握手的第三步，`linux1`发送了一个ACK段。
2.10.2 数据传输
`linux1.1082 > 206.132.41.203.www: P ...`: `linux1`发送了一个包含数据的段（由P标志表示）。
`206.132.41.203.www > linux1.1082: . ...`: `206.132.41.203`确认了收到的数据。
`206.132.41.203.www > linux1.1082: P ...`: `206.132.41.203`发送了一个包含数据的段。
`linux1.1082 > 206.132.41.203.www: . ...`: `linux1`确认了收到的数据。
`206.132.41.203.www > linux1.1082: P ...`: `206.132.41.203`再次发送了一个包含数据的段。
这个捕获显示了TCP连接的建立、数据的交换以及数据的确认。从中，我们可以看到TCP选项如MSS、SACK和时间戳在连接建立过程中的使用，这些选项帮助优化和提高TCP连接的性能。
2.11 如何使用`netstat`命令来查看和控制TCP连接
连接控制：`netstat`命令
2.11.1 使用`netstat`命令
在Unix/Linux系统上，使用`-a`选项；在Windows系统上，使用`-p tcp`选项。
2.11.2 示例输出
[linux30]$ netstat -atn
Connexions Internet actives (serveurs et établies)
Proto Recv-Q Send-Q Adresse locale Adresse distante Etat
tcp 0 0 0.0.0.0:32768 0.0.0.0:* LISTEN
tcp 0 0 127.0.0.1:32769 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:111 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:6000 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:631 0.0.0.0:* LISTEN
tcp 0 272 192.168.100.30:22 192.168.100.18:1994 ESTABLISHED2.11.3 解释
Proto`：协议类型，这里是TCP。
Recv-Q`和`Send-Q`：接收和发送队列中的数据量。
Adresse locale`：本地地址和端口。
Adresse distante`：远程地址和端口。
Etat`：连接状态。例如，`LISTEN`表示正在监听连接请求，`ESTABLISHED`表示已建立的连接。
通过`netstat`命令，用户可以查看系统上的所有活动TCP连接和监听的端口，这对于网络故障排查和系统监控非常有用。
2.12 TCP如何与应用程序交互以及数据如何在TCP和应用程序之间流动
TCP与应用程序
数据缓冲：应用程序将数据发送到其发送缓冲区（Buffer émission），而TCP从其接收缓冲区（Buffer réception）读取数据发送给应用程序。
TCP的工作方式：TCP将数据从发送缓冲区取出并按照其自己的流控制规则进行发送。同样，它将接收到的数据放入接收缓冲区，供应用程序读取。
应用程序的控制：应用程序没有直接控制TCP如何发送或接收数据。TCP根据其内部的流控制、拥塞控制和可靠性机制来决定何时发送数据。
这种设计允许TCP为应用程序提供一个可靠的、面向字节流的通信服务，而应用程序不需要关心底层的网络细节。
2.13 TCP流量控制是TCP协议提供的一种机制
确保发送方不会溢出接收方的缓冲区。这是一个端到端的控制，意味着只有发送方和接收方参与此过程，中间的路由器不存储有关TCP连接的状态信息，因此不参与流量控制。流量控制的细节如下：
2.13.1 窗口字段（Window）
TCP头部中的窗口字段用于流量控制。它告诉发送方接收方的缓冲区还能接受多少字节的数据，也就是接收窗口的大小。
2.13.2 接收缓冲区
接收方有一个固定大小的缓冲区（例如8KB、16KB、32KB等），用来暂存接收到的数据，直到应用程序读取它。
2.13.3 缓冲区溢出的防范
如果接收应用程序没有足够快地读取数据，接收缓冲区可能会被填满。为了防止溢出，接收方通过减小窗口字段的值来通知发送方减慢发送速度，甚至可以将窗口大小减到0，暂停数据发送。
2.13.4 窗口关闭（Win=0）情况
如果接收方将窗口大小设为0，发送方会定期（初始间隔为5秒，之后会翻倍，但通常不超过1分钟的上限）发送一个探测数据段来检测接收方的窗口大小是否有变化。这样做是为了在接收方应用程序开始读取数据，清空缓冲区后，能够恢复数据传输。
2.13.5 窗口重新打开
当接收应用程序处理了足够的数据，释放了缓冲区空间后，接收方会发送一个更新的窗口大小给发送方，从而可以继续数据传输。
这个机制确保了在网络中数据传输的稳定性和效率，防止因为接收方处理不及时而导致的数据丢失或重传。
2.14 TCP拥塞控制
TCP协议中用来解决网络拥塞问题的一套机制。尽管TCP的流量控制机制可以防止接收方被溢出，但它不足以应对整个网络中的拥塞问题。网络拥塞通常是由于网络中的一部分（如某个路由器或链路）负载过重，无法处理通过的所有数据包。以下是TCP协议如何应对这一问题：
2.14.1 拥塞的表现
当网络中的某个部分过载时，数据包可能会在路由器的队列中排队等待传输，导致延迟增加。
在严重拥塞的情况下，路由器可能会丢弃数据包，这会导致发送方必须重传这些数据包，从而进一步加剧网络拥塞。
2.14.2 拥塞控制机制
慢启动（Slow Start）：当一个新的TCP连接建立时，发送方开始以较小的拥塞窗口发送数据，随着每次成功的数据传输，窗口大小指数增长，直到达到一个阈值。
拥塞避免（Congestion Avoidance）：达到阈值后，窗口大小增长速度变为线性，以避免引起网络拥塞。
快重传（Fast Retransmit）：如果发送方接收到三个重复的ACK，它会立即重传丢失的数据包，而不是等待重传计时器超时。
快恢复（Fast Recovery）：在快重传之后，TCP减少其拥塞窗口大小而不是重新开始慢启动，以更快地从丢包情况中恢复。
2.14.3 适应网络变化
TCP使用这些机制来动态调整其发送速率，以响应网络条件的变化。例如，如果检测到数据包丢失（可能是由于网络拥塞），TCP会减少其发送速率。
2.14.4 不同网络段的速率差异
当TCP流经不同速率的网络段时（比如从100Mb/s降到2Mb/s），拥塞控制机制会帮助减少数据发送速率，以适应较慢链路的容量，从而防止在这些链路上发生拥塞。
总的来说，TCP的拥塞控制机制是为了在整个网络中平衡负载，避免拥塞，同时确保数据传输的效率和可靠性。
用来适应和缓解网络拥塞。这个机制包括多个部分，如往返时间（RTT）的测量，慢启动，以及快速恢复等：
2.14.4.1 往返时间（RTT）的确定
RTT是指数据包从发送方发送到接收方，再由接收方发送确认回到发送方所需的时间。
TCP使用特定的选项（如时间戳）来测量RTT，并据此调整重传计时器。正确的重传计时器设置对于有效地检测丢包和避免不必要的重传至关重要。
2.14.4.2 慢启动（Slow Start）机制
TCP使用一个称为拥塞窗口（cwnd，congestion window）的变量来限制在确认收到数据之前可以发送的最大数据量。
连接开始时，拥塞窗口被设置为一个最大报文段大小（MSS）。随着每个RTT，拥塞窗口的大小翻倍，直到达到一个预设的阈值。
当发生拥塞（比如丢包事件）时，拥塞窗口大小被大幅降低（通常是当前大小的一半），并且慢启动过程重新开始。
2.14.4.3 拥塞避免和快速恢复
当拥塞窗口的大小超过阈值时，其增长方式从指数增长变为线性增长，这是为了避免引起网络拥塞。
快速恢复机制用于处理丢包情况。如果发送方收到了重复的ACK，它意味着网络中存在丢包。此时，TCP会立即重传丢失的数据段，而不是等待重传计时器超时。
在多个连续的丢包情况下，选择性确认（SACK）可以用来仅重传丢失的数据段，而不是整个数据序列。
这些机制共同工作，使得TCP能够适应网络中的拥塞状况，通过动态调整数据传输速率来优化性能，同时减少因网络拥塞造成的数据丢失。
2.15 TCP的Path MTU Discovery机制
（由RFC 1191定义）是为了避免在TCP层发生分段而设计的。这个机制的目的是发现并使用最佳的最大传输单元（MTU）大小，以避免在网络路径上发生分段。以下是该机制的详细说明：
2.15.1 问题
在发送TCP数据包时，发送方的TCP层通常假定使用出口IP接口的MTU大小。例如，在以太网上，默认MTU通常是1500字节。
但是，在数据包到达接收方的路径上，可能存在MTU更小的链路（比如700字节）。如果TCP数据包的大小超过这个链路的MTU，那么该链路上的路由器需要对数据包进行分段处理，这可能导致效率降低和其他问题。
2.15.2 解决方案（Path MTU Discovery）
在发送TCP数据包时，设置IP头部的“不分段”（DF，Don't Fragment）位。这告诉路由器不要对这些数据包进行分段。
如果一个数据包的大小超过路径上某个链路的MTU，携带DF位的数据包不会被分段，而是被路由器丢弃。同时，路由器会向发送方发送一个ICMP（Internet Control Message Protocol）消息，告知数据包因为太大而被丢弃，并通常提供可以通过该链路传输的最大MTU大小。
接收到ICMP消息后，发送方知道了路径上的最大MTU大小，并将后续数据包的大小调整到这个MTU值以下，以避免分段。
这个机制确保了TCP数据包在整个传输路径上不会被分段，从而提高了网络效率和可靠性。通过动态发现并适应路径上的最小MTU，TCP可以优化数据包的大小，确保在网络中的顺畅传输。
这里是具体步骤：
2.15.2.1 发射第一个数据包
发送方（Em）向接收方（Rec）发送一个TCP数据包，其中序列号（seq）为1，数据包的大小为1448字节。这个尺寸是根据最大传输单元（MTU）计算得出的（1500字节的以太网MTU减去20字节的IP头部、12字节的TCP选项和20字节的TCP头部）。
使用tcpdump工具可以捕获到这个数据包的信息，例如序列号、大小、确认号（ack），以及TCP窗口大小（win）等。
2.15.2.2 接收到ICMP消息
当这个TCP数据包到达一个MTU只有700字节的中间路由器时，由于数据包大小超过了这个路由器的MTU，并且数据包设置了DF位，路由器将该数据包丢弃。
同时，路由器向发送方（Em）发送了一个ICMP消息，表明需要进行分段（need to frag），并提供了能够处理的最大MTU大小（700字节）。
2.15.2.3 调整数据包大小
发送方（Em）收到ICMP消息后，理解需要减小数据包的大小。新的数据包大小被调整为648字节（700字节的MTU减去12字节的TCP选项、20字节的TCP头部和20字节的IP头部）。
随后，发送方开始发送新的大小为648字节的TCP数据包。
这个过程展示了Path MTU Discovery如何在实际网络环境中工作，它使得发送方能够动态地调整TCP数据包的大小，以适应网络路径中的最小MTU，从而避免在路由器处的分段，提高数据传输的效率。
3. UDP协议
3.1 UDP（用户数据报协议）数据报的结构
UDP头部由以下几部分组成：
源端口（Port Source）：这个字段标识了发送数据报的应用程序。
目的端口（Port Destination）：这个字段标识了数据报的目的地应用程序。
长度（Longueur）：这个字段表示整个UDP数据报的长度，包括UDP头部和数据。
校验和（Somme de contrôle）：这个字段用于检查数据报在传输过程中是否出现错误。
数据（Données utiles）：这部分包含了实际传输的信息或应用数据。
UDP是一个无连接的协议，它不提供TCP所提供的各种保证，如数据到达确认、有序传输和重传机制。因此，UDP头部比TCP头部简单得多，使其在某些需要快速传输且可以容忍数据丢失的应用场景中更为有效，如实时视频或音频传输。
3.2 特点
UDP（用户数据报协议）是一种简单的网络通信协议：
a. 无连接：UDP不建立持久的连接，发送数据之前不需要在两端建立连接。这意味着发送方和接收方之间不会有握手过程。
b.无流量控制：UDP不进行流量控制，它不调整发送数据的速度以匹配接收方的处理速度。
c. 无确保数据送达：UDP不保证数据包的送达，也就是说，发送方不会得到是否成功送达接收方的确认。如果数据包丢失，UDP不会尝试重发。
d. 面向消息：UDP是一个面向消息的协议，它保留了消息的边界。这意味着每个UDP数据包是独立的，接收方得到的消息将保持发送时的数据边界，不会像TCP那样进行流式传输。
UDP是基于数据报的通信协议，它发送的数据单位是消息（或称数据报）。在UDP中，每个发送的消息都是独立的，并且消息在网络中的传输也是独立的，不像TCP那样是一个连续的数据流。
接收方收到的数据将保持发送方发送时的数据结构，即数据的边界是对齐的。这就是所谓的“模式消息”特性。例如，如果发送方发送了两个消息，每个消息包含100字节的数据，那么接收方也将分别接收到两个100字节的消息。这与TCP不同，TCP会将所有发送的数据作为一个连续流处理，接收方可能会在一个单独的数据块中接收到部分或全部数据，而不一定保持原始消息的边界。简单来说，UDP保留了发送时每个消息的完整性和边界，而不会将多个消息合并或拆分。
由于这些特性，UDP通常用于那些对实时性要求较高的应用，如实时视频会议、在线游戏或域名系统（DNS）查询，这些应用可以容忍一些数据包的丢失，但要求低延迟和低开销。
3.3 TCP和UDP在数据传输中对数据对齐方式的不同处理
3.3.1 TCP（传输控制协议）
它被描述为面向“字节流”的，意味着数据被视为一个连续的流，没有固定的边界。因此，发送方发送的数据可以在接收方那里被分割成不同大小的片段。例如，即使发送方将数据作为一个单独的大块发送，接收方也可能通过几个小块接收到全部数据，这就是所谓的不保证“数据帧”的对齐。
3.3.2 UDP（用户数据报协议）
它是面向“消息”的，这意味着数据在发送和接收时保持其边界。发送方发送的每个消息作为一个单独的单位在网络中传输，并且作为同样大小的一个单位被接收方接收。这保证了数据的对齐，接收方获取的数据结构和发送时完全一致。
图中的黑线代表数据的发送和接收，可以看到TCP的数据在接收时可能会与发送时不一致，而UDP保持了数据的一致性。这种特性使得UDP适用于那些需要维护数据边界的应用场景，如视频流或VoIP通话。
4. 应用层协议的实现和它们与数据编码及会话概念的关系
4.1 应用层协议的实
应用层协议由应用程序实现，有专门的应用程序接口（API）来支持网络通信。
Sockets（BSD）：在Berkeley Software Distribution（BSD）版本的UNIX操作系统中引入，把网络通信视为文件操作。开发者需要自己实现通信协议的逻辑。
Transport Services API：IETF的草案中提出了一种通用API，目的是提供一个标准的接口以支持不同的传输协议。
RPC（远程过程调用）：隐藏了网络通信的复杂性，允许开发者像调用本地函数一样调用远程服务器上的过程。
CORBA（公共请求代理架构：是面向对象编程的一个扩展，用于分布式应用程序的开发。
还提到了存在许多特定用途的中间件。
4.2 数据的编码
文本协议：如SMTP、HTTP（1.x）、SIP、SDP等，这些协议使用简单的文本格式，易于读取和调试。
编码协议：
ASN.1/BER/PER：用于如H.323和SNMP等协议，提供了一种结构化数据的描述和编码方法。
XDR（外部数据表示）：用于NFS和NIS等协议，提供了一种在不同系统之间转换和编码数据的标准方法。
会话概念：某些协议，如SIP、SDP、BEEP，以及Web上的cookies，都包含了会话的概念。在这些协议中，会话用于在一系列的交换信息中保持状态和上下文信息。
总体来说，应用层协议是网络通信的高层实现，它们依赖于传输层协议（如TCP和UDP）来实现端到端的数据传输。这些协议为不同类型的网络交互提供了必要的规则和结构，从而使得网络服务能够进行。
4.3 HTTP请求的典型格式
它展示了一个客户端（如Web浏览器）如何向服务器请求一个网页。这个过程包含以下几个部分：
GET /index.fr.php HTTP/1.1
Host: www.enst-bretagne.fr
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4)
Gecko/20030624 Netscape/7.1 (ax)
Accept: text/xml,application/xml,.....
Accept-Language: fr,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Referer: http://www.enst-bretagne.fr/4.3.1 请求行
GET /index.fr.php HTTP/1.1：这是请求行，它指示使用GET方法请求名为`/index.fr.php`的资源，使用的HTTP版本是1.1。
4.3.2 请求头部
Host: www.enst-bretagne.fr`：指定请求的服务器。
User-Agent: Mozilla/5.0...`：告知服务器客户端使用的浏览器类型和版本。
Accept: text/xml,application/xml,...`：告知服务器客户端能够处理的内容类型。
Accept-Language: fr,en;q=0.5`：告知服务器客户端首选的语言。
Accept-Encoding: gzip,deflate`：告知服务器客户端可以接受的编码类型，通常用于压缩。
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7`：指明客户端可以接受的字符集。
Keep-Alive: 300`：请求服务器保持连接一段时间，而不是请求后立即关闭。
Connection: keep-alive`：指示连接应保持活跃状态。
Referer: http://www.enst-bretagne.fr/`：告知服务器用户是从哪个页面链接过来的。
请求头部包含了很多关键信息，使得服务器可以根据客户端的能力和偏好返回适当的响应。例如，服务器可以根据`Accept-Language`头部返回不同语言的网页版本，也可以根据`User-Agent`提供特定浏览器兼容的内容。
4.4 HTTP响应的组成部分
服务器在成功处理客户端的GET请求后返回了一个网页。
HTTP/1.1 200 OK
Date: Fri, 09 Jul 2004 09:20:06 GMT
Server: Apache/1.3.22 (Unix) PHP/4.0.4pl1 mod_fastcgi/2.2.10 PHP/3.0.....
X-Powered-By: PHP/4.0.4pl1
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: text/html
Content-Language: fr
<HTML>
<HEAD>
<TITLE>[ENST Bretagne] école formation ingénieur</TITLE>
<!-L’école nationale supérieure des télécommunications de Bretagne offre
un large choix de formation: ingénieur, mastères, télécom, thèse, DEA...->
<meta name="robots" content="noindex,nofollow">
<meta name="description" content="L’école nationale supérieure des télécommunications de Bretagne offre un
large choix de formation: ingénieur, mastères, télécom, thèse, DEA...">
<meta name="keywords" content="école ingénieur, formation ingénieur, école nationale supérieure
télécommunications, Bretagne, mastères, télécom, thèse, DEA, ENST, GET, étude télécommunication,
enseignement supérieur, technologie information, communication, TIC, concours, mines-ponts, alternance,
projets européens, recherche, laboratoire, grandes écoles, formation continue, diplôme, Brest, Rennes,
ECOLE INGENIEUR, FORMATION INGENIEUR">
<LINK rel="stylesheet" href="css/style.css">4.4.1 状态行
`HTTP/1.1 200 OK`：状态行显示了HTTP版本（1.1），状态码（200）和状态消息（OK），表示请求已成功处理。
4.4.2 响应头部
Date: Fri, 09 Jul 2004 09:20:06 GMT`：响应生成的日期和时间。
Server: Apache/1.3.22...`：服务器软件的信息。
X-Powered-By: PHP/4.0.4pl1`：服务器上运行的脚本引擎的版本。
Keep-Alive: timeout=15, max=100`：Keep-Alive头部指示连接保持活动的时间和最大请求数。
Connection: Keep-Alive`：连接将保持打开状态，以便客户端可以继续通过同一连接发送请求。
Transfer-Encoding: chunked`：数据以一系列块的形式发送，不是一次性发送。
Content-Type: text/html`：响应内容的MIME类型。
Content-Language: fr`：响应内容的语言。
4.4.3 响应正文
<HTML>`...：实际的HTML文档开始，包括头部（HEAD）和标题（TITLE）等。
HTML注释和meta标签提供了页面内容的附加信息，如页面描述、关键词、机器人指令（如不被搜索引擎索引或跟踪）等。
LINK标签指向CSS文件，用于定义页面的样式。
状态码200表示请求已被成功处理，并且服务器提供了请求的资源作为响应正文。这个HTML文档可能包含了文本、图片链接、CSS样式链接、JavaScript脚本链接等，浏览器会解析这个HTML文档并显示成网页。
4.5 SMTP（简单邮件传输协议）交换的例子
它展示了电子邮件发送过程中客户端（发送方S）和服务器（接收方R）之间的通信。SMTP是用于发送和接收电子邮件的互联网标准协议。以下是交换过程的步骤：
S: MAIL FROM:<Smith@Alpha.ARPA>
R: 250 OK
S: RCPT TO:<Jones@Beta.ARPA>
R: 250 OK
S: RCPT TO:<Green@Beta.ARPA>
R: 550 No such user here
S: RCPT TO:<Brown@Beta.ARPA>
R: 250 OK
S: DATA
R: 354 Start mail input; end with <CRLF>.<CRLF>
S: Blah blah blah...
S: ...etc. etc. etc.
S: <CRLF>.<CRLF>
R: 250 OK4.5.1 MAIL FROM
客户端开始一个邮件事务，通过指定发件人地址：`MAIL FROM:<Smith@Alpha.ARPA>`。
服务器回应`250 OK`表示接受了发件人地址。
4.5.2 RCPT TO
客户端指定收件人地址：`RCPT TO:<Jones@Beta.ARPA>`。
服务器再次回应`250 OK`表示接受了收件人地址。
4.5.3 第二个收件人
客户端尝试添加另一个收件人：`RCPT TO:<Green@Beta.ARPA>`。
服务器回应`550 No such user here`表示指定的用户在服务器上不存在。
4.5.4 第三个收件人
客户端继续添加另一个收件人：`RCPT TO:<Brown@Beta.ARPA>`。
服务器回应`250 OK`表示接受了这个收件人地址。
4.5.5 DATA
客户端请求开始发送邮件正文：`DATA`。
服务器回应`354 Start mail input; end with <CRLF>.<CRLF>`，指示客户端可以开始发送邮件内容，并应该以一个点（`.`）在新的一行结束邮件内容。
4.5.6 邮件正文
客户端发送邮件正文，可能包含多行：`Blah blah blah...`和`...etc. etc. etc.`。
客户端以一个点（`.`）在新的一行结束邮件内容，符合服务器的指示。
4.5.7 邮件发送完成
服务器确认邮件已被接收并处理，回应`250 OK`。
这个过程遵循RFC 821（SMTP的原始规范，现在已被RFC 5321更新），显示了SMTP的基本交互模式，其中客户端和服务器之间的每个步骤都有明确的请求和响应。
电子邮件的工作原理包括用户地址的标准格式、客户端和服务器工具的使用，以及DNS在电子邮件传输中的作用。
4.5.7.1 电子邮件地址格式
电子邮件地址通常遵循`用户名@服务器名称.域`的格式。例如，`john.doe@example.com`，其中`john.doe`是用户名，`example.com`是邮件服务器所在的域。
4.5.7.2 客户端工具（MUA：Mail User Agent）
MUA是指用户直接用来处理电子邮件的客户端应用，如Netscape、Outlook、Lotus Notes等。
当发送电子邮件时，客户端应用使用SMTP（简单邮件传输协议）与邮件服务器通信。
接收邮件时，客户端可能使用POP（邮局协议）或IMAP（互联网消息访问协议），它们可以是加密的或非加密的。
4.5.7.3 服务器工具（MTA：Message Transfer Agent）
MTA是在后台处理邮件传输的服务器应用，如Microsoft IIS、Sendmail、Postfix等。
它们负责接收、转发、传递和发送电子邮件。服务器之间的通信也使用SMTP。
4.5.7.4 域名系统（DNS）
DNS在邮件传输中扮演着关键角色，特别是在处理MX（邮件交换）记录时。
当电子邮件被发送时，发送方的邮件服务器会查询收件方域名的MX记录来确定邮件应该被送往哪个邮件服务器。
简而言之，用户通过MUA撰写并发送邮件，邮件通过SMTP发送到MTA。MTA可能会查询DNS来确定下一步如何路由邮件，最终将邮件递送到收件人的MUA，收件人可以通过POP或IMAP协议接收邮件。