TCP概述
- 传输控制协议（TCP，Transmission Control Protocol）是为了在不可靠的互联网络上提供可靠的端到端字节流而专门设计的一个传输协议。TCP位于TCP/IP模型的传输层，TCP作为传输控制协议，TCP需要依赖网络协议为主机提供可用的传输路径。
- TCP允许一个主机同时运行多个应用进程。每台主机可以拥有多个应用端口，每对端口号、源和目标IP地址的组合唯一地标识了一个会话。
- 端口分为知名端口和动态端口。有些网络服务会使用固定的端口，这类端口称为知名端口，端口号范围为0-1023。如FTP、HTTP、Telnet、SNMP服务均使用知名端口。动态端口号范围从1024到65535，这些端口号一般不固定分配给某个服务，也就是说许多服务都可以使用这些端口。只要运行的程序向系统提出访问网络的申请，那么系统就可以从这些端口号中分配一个供该程序使用。
TCP报文格式
- SP（Source Port）：源端口号表示报文的发送端口，占16位。源端口和源IP地址组合起来，可以标识报文的发送地址。
- DP（Destination Port）：目的端口号表示报文的接收端口，占16位。目的端口和目的IP地址相结合，可以标识报文的接收地址。
- SN（Sequence Number）：
- TCP传输过程中，在发送端出的字节流中，传输报文中的数据部分的每一个字节都有它的编号。序号（SequenceNumber）占32位，发起方发送数据时，都需要标记序号。
- 序号（Sequence Number）的语义与SYN控制标志（ControlBits）的值有关。根据控制标志（Control Bits）中的SYN是否为1，序号（Sequence Number）表达不同的含义：
- 当SYN = 1时，当前为连接建立阶段，此时的序号为初始序号ISN((Initial Sequence Number)，通过算法来随机生成序号；
- 当SYN = 0时在数据传输正式开始时，第一个报文的序号为 ISN+1，后面的报文的序号，为前一个报文的SN值+TCP报文的净荷字节数(不包含TCP头)。比如，如果发送端发送的一个TCP帧的净荷为12byte，序号为5，则发送端接着发送的下一个数据包的时候，序号的值应该设置为5+12=17。
- 在数据传输过程中，TCP协议通过序号（Sequence Number）对上层提供有序的数据流。发送端可以用序号来跟踪发送的数据量；接收端可以用序号识别出重复接收到的TCP包，从而丢弃重复包；对于乱序的数据包，接收端也可以依靠序号对其进行排序。
- AN（Acknowledgment Number）：确认序号（Acknowledgment Number）标识了接收端期望接收的字节序列。如果设置了ACK控制位，确认序号的值表示一个准备接收的包的序列码，注意，它所指向的是准备接收的包，也就是下一个期望接收的包的序列码。
- 当SYN=1，ACK=1时，当前为连接建立阶段，此时的序号为初始序号ISN((Initial Sequence Number)，通过算法来随机生成序号；确认序列号为对端ISN的序列号加1（对端ISN+1）
- 当SYN=0，ACK=,1时，此时为数据传输阶段，AN=对端SN号+1，表示本端已接收到报文，并告诉对端下一个报文的所需要的SN号。
Data Offset（Header Length）：TCP头部报文的长度，最多有60字节的首部，若无选项字段，正常为20字节。（不包含Option、Padding、Data的情况下）
Reserved：保留位，必须填0，6bit
标识位：6bit，由URG、ACK、PSH、RST、SYN、FIN组成，
- URG：紧急指针有效标识。它告诉系统此报文段中有紧急数据，应尽快传送（相当于高优先级的数据）。
- ACK：确认序号有效标识。只有当ACK=1时确认号字段才有效。当ACK=0时，确认号无效。
- PSH：标识接收方应该尽快将这个报文段交给应用层。接收到PSH = 1的TCP报文段，应尽快的交付接收应用进程，而不再等待整个缓存都填满了后再向上交付。
- RST:重建连接标识。当RST=1时，表明TCP连接中出现严重错误（如由于主机崩溃或其他原因），必须释放连接，然后再重新建立连接。
- SYN:同步序号标识，用来发起一个连接。SYN=1表示这是一个连接请求或连接接受请求。
- FIN:发端完成发送任务标识。用来释放一个连接。FIN=1表明此报文段的发送端的数据已经发送完毕，并要求释放连接。
Window:TCP的流量控制，窗口起始于确认序号字段指明的值，这个值是接收端期望接收的字节数。窗口最大为65535字节。
CheckSum:校验字段，包括TCP首部和TCP数据，是一个强制性的字段，一定是由发端计算和存储，并由收端进行验证。在计算检验和时，要在TCP报文段的前面加上12字节的伪首部。
Urgent Pointer:紧急指针，只有当URG标志置1时紧急指针才有效。TCP的紧急方式是发送端向另一端发送紧急数据的一种方式。紧急指针指出在本报文段中紧急数据共有多少个字节（紧急数据放在本报文段数据的最前面）。
Options:可选字段。TCP协议最初只规定了一种选项，即最长报文段长度（只包含数据字段，不包括TCP首部），又称为MSS（Maximum Segment Size，最长TCP数据段长度）。
- MSS告诉对方TCP“我的缓存所能接收的报文段的数据字段的最大长度是MSS个字节”。
- 新的RFC规定以下几种选型：选项表结束，空操作，最大报文段长度，窗口扩大因子，时间戳。
- 由于可选项和填充部分不是必须的，所以TCP报文首部最小长度为20个字节。
- 可选项和填充部分的长度为4n字节（n是整数），该部分是根据需要而增加的选项。如果不足4n字节，要加填充位，使得选项长度为32位（4字节）的整数倍，具体的做法是在这个字段中加入额外的零，以确保TCP头是32位（4字节）的整数倍。
- 一个 IP 分组首部（通常为 20 字节）
- 一个 TCP 段首部（通常为 20 字节）
- 一个 TCP 数据块（0 个或多个字节）
TCP可靠性
- 应用数据被分割成TCP认为最适合发送的数据块。这和UDP完全不同，应用程序产生的数据长度将保持不变。由TCP传递给IP的信息单位称为报文段或段（segment）。
- 当TCP发出一个段后，它启动一个定时器，等待目的端确认收到这个报文段。如果不能及时收到一个确认，将重发这个报文段。当TCP收到发自TCP连接另一端的数据，它将发送一个确认。TCP有延迟确认的功能，在此功能没有打开，则是立即确认。功能打开，则由定时器触发确认时间点。
- TCP将保持它首部和数据的检验和。这是一个端到端的检验和，目的是检测数据在传输过程中的任何变化。如果收到段的检验和有差错，TCP将丢弃这个报文段和不确认收到此报文段（希望发端超时并重发）。
- 既然TCP报文段作为IP数据报来传输，而IP数据报的到达可能会失序，因此TCP报文段的到达也可能会失序。如果必要，TCP将对收到的数据进行重新排序，将收到的数据以正确的顺序交给应用层。
- 既然IP数据报会发生重复，TCP的接收端必须丢弃重复的数据。
- TCP还能提供流量控制。TCP连接的每一方都有固定大小的缓冲空间。TCP的接收端只允许另一端发送接收端缓冲区所能接纳的数据。这将防止较快主机致使较慢主机的缓冲区溢出。
TCP三次握手&传输数据&四次挥手
- 发送方，在TCP模块接收到应用层下发的数据后，会为应用层数据封装TCP头部，称为TCP数据段（接收数据）
- 发送方，TCP模块在发送TCP数据段前（即下发三层IP模块前），需首先向接收方的TCP模块发送TCP控制段，通过与接收方的TCP模块进行TCP控制段的交互而建立起TCP会话（TCP Session）（三次握手）
- 发送方，在TCP会话建立之后，与接收方的TCP模块之间才开始进行TCP数据段的传递。在TCP数据段传递期间，发送方和接收方的TCP模块之间一直保持TCP控制段的交互/保持TCP会话（传输数据）
- 在数据段传递完毕后，由接收方主动发起会话结束，同样通过TCP控制段的交互来终止。（四次挥手）
Closed：TCP会话关闭状态，空状态
- 主动（Active）开启，创建（Create）TCB，主动输出TCP_SYN报文后进入SYN_SENT状态
Listen：
- 被动（Passive）开启，创建（create）或者删除(delete)TCB，监听状态，监听远端TCP报文和目的端口的连接请求。接收TCP_SYN报文后，输出TCP_SYN_ACK报文后进入SYN_Receiverd状态
SYN_Received：输出TCP_SYN_ACK报文后，等待TCP_ACK报文的状态，接收TCP_ACK报文后进入Established。
SYN_Sent：主动输出TCP_SYN报文后，等待远端TCP_SYN_ACK回复的状态，输出TCP_ACK后进入Established状态
Established:TCP会话建立成功，传递TCP数据段，下发IP模块的状态。
FIN_Wait-1：数据传递完毕后，接收方主动输出TCP_FIN_ACK报文，请求结束会话与确认数据的接收，且等待确认会话结束的TCP_ACK报文的状态，表示主动断开方没有业务数据要发送给对方，准备结束Socket
FIF_Wait-2：接收TCP_FIN_ACK报文后，等待第3、4握手的装状态。
Close-Wait：
- 等待本地用户的连接终止请求。
- 收到接收方发送的TCP_FIN_ACK段，发送TCP_ACK报文后，此时被动断开方依然需要传递TCP数据段，直到被动方剩余数据发送完成后，或者CLOSE-WAIT（关闭等待）截止后，发送TCP_FIN_ACK段后进入LAST-ACK(最后确认)状态
Closing：
- 等待远端TCP 的连接终止请求确认。
- 接收TCP_FIN报文后，输出TCP_ACK报文，此时对端依然传递TCP数据段，等待远端主动发送TCP_FIN控制段的时间，或者
LAST-ACK：待剩余数据发送完成后，或者CLOSE-WAIT（关闭等待）截止后，被动断开方会向主动断开方发送一个FIN+ACK结束响应报文，表示被动断开方的数据都发送完了，然后，被动断开方进入LAST_ACK状态。
Time-Wait：向主动方发送TCP_ACK段后，进入2MSL的等待时间，超时后被动方得知主动方已关闭。
TCB（TCP Control Block，传输控制模块）：它用于记录tcp协议运行过程中的 变量。对于有多个连接的tcp，每个连接都有一个tcb。tcb结构的定义包括这个连接使用 的源端口、目的端口、目的ip、序号、应答序号、对方窗口大小、己方窗口大小、tcp状态、top输入/输出队列、应用层输出队列、tcp的重传有关变量。
TCP三次握手
1、发送方需要输出TCP数据段，需要主动发送TCP控制段，建立会话，主动方发送TCP_SYN(Seq=x)，进入SYN_Sent状态，等待接收方的TCP_SYN_ACK控制段。
2、被动方接收到TCP_SYN控制段，向主动方回复TCP_SYN_ACK控制段（Seq=Y，ACK=X+1）,进入SYN_Receiverd状态，等待主动方回复TCP_ACK控制段
3、主动方接收到TCP_SYN_ACK控制段后，向被动回复TCP_ACK(Seq=X+1,ACK=Y+1)控制段，并进入Established状态，创建TCP会话，开始传输TCP数据段。
4、被动方接收到TCP_ACK控制后，进入Established状态，创建TCP会话，开始传输TCP数据段
5、如两端都有TCP数据段需要传输，则需要建立两端都主动创建一个会话（三次握手），用于本端的TCP数据段传递。
TCP数据传输
1、创建TCP会话后，为TCP数据段传输阶段，发送方主动向接收方发送TCP_ACK（Seq=X+1+TCP-Payload，ACK=Y+1），第一个TCP数据段的Seq延续使用三次握手的第三次TCP控制的Seq，加上数据载荷大小，后续TCP数据段的Seq则为上一个TCP数据报文的Seq+Payload
2、接收方侧，创建TCP会话后，接收到TCP数据段后，
3、在三次握手&四次挥手中，会为ACK+1，在数据传输中则直接复制发送方Seq到ACK进行回复
TCP四次挥手
1、第一次挥手：主动断开方（可以是客户端，也可以是服务器端），向对方发送一个TCP_FIN_ACK（Seq=X{承接上一个报文的ACK值}，ACK=Y{承接上一个报文的Seq+Payload值}）控制段结束请求报文。发送完成后，主动断开方进入FIN_WAIT_1状态，这表示主动断开方没有业务数据要发送给对方，准备关闭SOCKET连接了。
- 若先于对端TCP_ACK回复前，进行了第3、4次握手,则进入Closing状态，Closing状态后接收到第2次握手的TCP_ACK回复则进入TIME_WAIT状态
- 若接收到对端TCP_ACK回复，则进入FIN_WAIT_2状态，且等待进行第3、4次挥手
2、第二次挥手：在收到了主动方发送的TCP_FIN断开请求报文后，被动方会回复一个TCP_ACK(Seq=Y,ACK=X+1)响应报文，该ACK确认报文的含义是：“我同意你的连接断开请求”。之后，被动断开方就进入了CLOSE-WAIT（关闭等待）状态，TCP协议服务会通知高层的应用进程，对方向本地方向的连接已经关闭，对方已经没有数据要发送了，若本地还要发送数据给对方，对方依然会接受。被动断开方的CLOSE-WAIT（关闭等待）还要持续一段时间，也就是整个CLOSE-WAIT状态持续的时间。
3、第三次挥手：在发送完成ACK报文后，被动断开方还可以继续完成业务数据的发送，待剩余数据发送完成后，或者CLOSE-WAIT（关闭等待）截止后，被动断开方会向主动断开方发送一个FIN+ACK结束响应报文，表示被动断开方的数据都发送完了，然后，被动断开方进入LAST_ACK（最后确认）状态。
4、第四次挥手：主动断开方收在到FIN+ACK断开响应报文后，还需要进行最后的确认，向被动断开方发送一个ACK确认报文，然后，自己就进入TIME_WAIT状态，等待超时后最终关闭连接。处于TIME_WAIT状态的主动断开方，在等待完成2MSL的时间后，如果期间没有收到其他报文，则证明对方已正常关闭，主动断开方的连接最终关闭。
5、双倍TCP段最大生命时间（2MSL，2*Maximum Segment Lifetime）：指的是一个TCP报文片段在网络中最大的存活时间，具体来说，2MSL对应于一次消息的来回（一个发送和一个回复）所需的最大时间。如果直到2MSL，主动断开方都没有再一次收到对方的报文（如FIN报文），则可以推断ACK已经被对方成功接收，此时，主动断开方将最终结束自己的TCP连接。所以，TCP的TIME_WAIT状态也称为2MSL等待状态。
6、因两端都要传输数据，所以两端会发送一次TCP控制段，两端都进行一次三次握手，因此在最后拆除时进行4次握手，结束本端的会话。
TCP滑动窗口&分片&重传机制
Window:TCP的流量控制，窗口起始于确认序号字段指明的值，这个值是接收端期望接收的字节数。窗口最大为65535字节。（期望的）（Byte）
Options:可选字段。TCP协议最初只规定了一种选项，即最长报文段长度（只包含数据字段，不包括TCP首部），又称为MSS（Maximum Segment Size，最长TCP数据段长度）。
- MSS告诉对方TCP“我的缓存所能接收的报文段的数据字段的最大长度是MSS个字节”。（我能接受的）（Byte）
数据分片
数据从主机传送到另一个主机往往要经过路由器、网关等设备。
这些设备都要对经过的数据进行处理。由于这些设备处理数据有一定的限制，不能处理超过额定字节的数据，所以发送的时候需要确定发送数据包的最大字节数。
这个最大字节数被称为最大消息长度（Maximum Segment Size，MSS）。当要发送的数据超过该值，就需要将数据分为多个包，依次发送。该操作被称为数据分片。 MSS 是 TCP 数据包每次能够传输的最大数据量。通常，最大值为 1460 字节。如果发送的数据包大小大于 MSS 值，数据包将会被分片传输。分片原理如图所示。
其中，第 1 次和第 2 次握手包的 TCP 首部包含 MSS 选项，互相通知对方网络接口能够适应的 MSS 的大小，然后双方会使用较小的 MSS 值进行传输。
滑动窗口机制
在进行数据传输时，如果传输的数据比较大，就需要拆分为多个数据包进行发送。TCP 协议需要对数据进行确认后，才可以发送下一个数据包，如图所示。
从上图中可以看到，发送端每发送一个数据包，都需要得到接收端的确认应答以后，才可以发送下一个数据包。这样一来，就会在等待确认应答包环节浪费时间。为了避免这种情况，TCP引入了窗口概念。窗口大小指的是不需要等待确认应答包而可以继续发送数据包的最大值。
例如，窗口大小为 3，数据包的传输如图所示。
从上图中可以看到，发送端发送第一个数据包（1-1024），没有等待对应的确认应答包，就继续发送第二个数据包（1001-2000）和第三个包（2001-3000）。当收到第3个数据包的确认应答包时，会连续发送3个数据包（3001-4000，4001-5000，5001-6000）。当收到第6个数据包的确认应答包时，又会发送3个数据包（6001-7000，7001-8000，8001-9000）。
以这种方式发送，就可以省去多个数据包（第1、2、4、5、7、8个）的确认应答包时间，从而避免了网络的吞吐量的降低。
窗口大小指的是可以发送数据包的最大数量。在实际使用中，它可以分为两部分。第一部分表示数据包已经发送，但未得到确认应答包；第二部分表示允许发送，但未发送的数据包。在进行数据包发送时，当发送了最大数量的数据包（窗口大小数据包），有时不会同时收到这些数据包的确认应答包，而是收到部分确认应答包。
那么，此时窗口就通过滑动的方式，向后移动，确保下一次发送仍然可以发送窗口大小的数据包。这样的发送方式被称为滑动窗口机制。设置窗口大小为 3，滑动窗口机制原理如图所示。
上图中，每 1000 个字节表示一个数据包。发送端同时发送了 3 个数据包（2001-5000），接收端响应的确认应答包为“下一个发送4001”，表示接收端成功响应了前两个数据包，没有响应最后一个数据包。此时，最后一个数据包要保留在窗口中。
由于窗口大小为 3，发送端除了最后一个包以外，还可以继续发送下两个数据包（5001-6000 和 6001-7000）。窗口滑动到 7001 处。
TCP保活机制
保活功能在默认情况下是关闭的。TCP连接的任何一端都可以请求打开这一功能。保活功能可以被设置在连接的一端、两端,或者两端都没有。
有几个配置参数可以用来控制保活 功能的操作。如果在一段时间(称为保活时间, keepalive time)内连接处于非活动状态,开启保活功能的一端将向对方发送一个保活探测报文。如果发送端没有收到响应报文,那么经过一个已经提前配置好的保活时间间隔(keepalive interval),将继续发送保活探测报文,直到发送探测报文的次数达到保活探测数(keepalive probe),这时对方主机将被确认为不可到达,连接也将被中断。
保活探测报文为一个空报文段(或只包含1字节)。它的序列号等于对方主机发送的 ACK报文的最大序列号减1。因为这一序列号的数据段已经被成功接收,所以不会对到达的报文段造成影响,但探测报文返回的响应可以确定连接是否仍在工作。探测及其响应报文都不包含任何新的有效数据(它是“垃圾”数据),当它们丢失时也不会进行重传。
TCP保活功能工作过程中,开启该功能的一端会发现对方处于以下四种状态之一：
- 对方主机仍在工作,并且可以到达。对方的TCP响应正常,并且请求端也知道对方 在正常工作。请求端将保活计时器重置(重新设定为保活时间值)。如果在计时器超时之前有应用程序通过该连接传输数据,那么计时器将再次被设定为保活时间值。
- 对方主机已经崩溃,包括已经关闭或者正在重新启动。这时对方的TCP将不会响应。 请求端不会接收到响应报文,并在经过保活时间间隔指定的时间后超时。超时前,请求端会 持续发送探测报文,一共发送保活探测数指定次数的探测报文,如果请求端没有收到任何探 测报文的响应,那么它将认为对方主机已经关闭,连接也将被断开。
- 客户主机崩溃并且已重启。在这种情况下,请求端会收到一个对其保活探测报文的响应,但这个响应是一个重置报文段,请求端将会断开连接。
- 对方主机仍在工作,但是由于某些原因不能到达请求端(例如网络无法传输,而且可 圃 能使用ICMP通知也可能不通知对方这一事实)。这种情况与状态2相同,因为TCP不能区 分状态2与状态4,结果都是没有收到探测报文的响应。
- 请求端不必担心对方主机正常关闭然后重启(不同于主机崩溃)的情况。当系统关机时, 所有的应用进程也会终止(即对方的进程),这会使对方的TCP发送一个FIN。请求端接收 到FIN后,会向请求端进程报告文件结束,并在检测到该状态后退出。
保活机制的弊端
- 在出现短暂的网络错误的时候，保活机制有可能会使一个好的连接断开；
- 保活机制会占用不必要的带宽；
知名端口（0-1023）
常见TCP/UDP端口号大全_大白熊_BlankBear的博客-CSDN博客
| 端口号码 / 层 | 名称 | 注释 |
| 1 | tcpmux | TCP 端口服务多路复用 |
| 5 | rje | 远程作业入口 |
| 7 | echo | Echo 服务 |
| 9 | discard | 用于连接测试的空服务 |
| 11 | systat | 用于列举连接了的端口的系统状态 |
| 13 | daytime | 给请求主机发送日期和时间 |
| 17 | qotd | 给连接了的主机发送每日格言 |
| 18 | msp | 消息发送协议 |
| 19 | chargen | 字符生成服务；发送无止境的字符流 |
| 20 | ftp-data | FTP 数据端口 |
| 21 | ftp | 文件传输协议（FTP）端口；有时被文件服务协议（FSP）使用 |
| 22 | ssh | 安全 Shell（SSH）服务 |
| 23 | telnet | Telnet 服务 |
| 25 | smtp | 简单邮件传输协议（SMTP） |
| 37 | time | 时间协议 |
| 39 | rlp | 资源定位协议 |
| 42 | nameserver | 互联网名称服务 |
| 43 | nicname | WHOIS 目录服务 |
| 49 | tacacs | 用于基于 TCP/IP 验证和访问的终端访问控制器访问控制系统 |
| 50 | re-mail-ck | 远程邮件检查协议 |
| 53 | domain | 域名服务（如 BIND） |
| 63 | whois++ | WHOIS++，被扩展了的 WHOIS 服务 |
| 67 | bootps | 引导协议（BOOTP）服务；还被动态主机配置协议（DHCP）服务使用 |
| 68 | bootpc | Bootstrap（BOOTP）客户；还被动态主机配置协议（DHCP）客户使用 |
| 69 | tftp | 小文件传输协议（TFTP） |
| 70 | gopher | Gopher 互联网文档搜寻和检索 |
| 71 | netrjs-1 | 远程作业服务 |
| 72 | netrjs-2 | 远程作业服务 |
| 73 | netrjs-3 | 远程作业服务 |
| 73 | netrjs-4 | 远程作业服务 |
| 79 | finger | 用于用户联系信息的 Finger 服务 |
| 80 | http | 用于万维网（WWW）服务的超文本传输协议（HTTP） |
| 88 | kerberos | Kerberos 网络验证系统 |
| 95 | supdup | Telnet 协议扩展 |
| 101 | hostname | SRI-NIC 机器上的主机名服务 |
| 102 | iso-tsap | ISO 开发环境（ISODE）网络应用 |
| 105 | csnet-ns | 邮箱名称服务器；也被 CSO 名称服务器使用 |
| 107 | rtelnet | 远程 Telnet |
| 109 | pop2 | 邮局协议版本2 |
| 110 | pop3 | 邮局协议版本3 |
| 111 | sunrpc | 用于远程命令执行的远程过程调用（RPC）协议，被网络文件系统（NFS）使用 |
| 113 | auth | 验证和身份识别协议 |
| 115 | sftp | 安全文件传输协议（SFTP）服务 |
| 117 | uucp-path | Unix 到 Unix 复制协议（UUCP）路径服务 |
| 119 | nntp | 用于 USENET 讨论系统的网络新闻传输协议（NNTP） |
| 123 | ntp | 网络时间协议（NTP） |
| 137 | netbios-ns | 在红帽企业 Linux 中被 Samba 使用的 NETBIOS 名称服务 |
| 138 | netbios-dgm | 在红帽企业 Linux 中被 Samba 使用的 NETBIOS 数据报服务 |
| 139 | netbios-ssn | 在红帽企业 Linux 中被 Samba 使用的NET BIOS 会话服务 |
| 143 | imap | 互联网消息存取协议（IMAP） |
| 161 | snmp | 简单网络管理协议（SNMP） |
| 162 | snmptrap | SNMP 的陷阱 |
| 163 | cmip-man | 通用管理信息协议（CMIP） |
| 164 | cmip-agent | 通用管理信息协议（CMIP） |
| 174 | mailq | MAILQ |
| 177 | xdmcp | X 显示管理器控制协议 |
| 178 | nextstep | NeXTStep 窗口服务器 |
| 179 | bgp | 边界网络协议 |
| 191 | prospero | Cliffod Neuman 的 Prospero 服务 |
| 194 | irc | 互联网中继聊天（IRC） |
| 199 | smux | SNMP UNIX 多路复用 |
| 201 | at-rtmp | AppleTalk 选路 |
| 202 | at-nbp | AppleTalk 名称绑定 |
| 204 | at-echo | AppleTalk echo 服务 |
| 206 | at-zis | AppleTalk 区块信息 |
| 209 | qmtp | 快速邮件传输协议（QMTP） |
| 210 | z39.50 | NISO Z39.50 数据库 |
| 213 | ipx | 互联网络分组交换协议（IPX），被 Novell Netware 环境常用的数据报协议 |
| 220 | imap3 | 互联网消息存取协议版本3 |
| 245 | link | LINK |
| 347 | fatserv | Fatmen 服务器 |
| 363 | rsvp_tunnel | RSVP 隧道 |
| 369 | rpc2portmap | Coda 文件系统端口映射器 |
| 370 | codaauth2 | Coda 文件系统验证服务 |
| 372 | ulistproc | UNIX Listserv |
| 389 | ldap | 轻型目录存取协议（LDAP） |
| 427 | svrloc | 服务位置协议（SLP） |
| 434 | mobileip-agent | 可移互联网协议（IP）代理 |
| 435 | mobilip-mn | 可移互联网协议（IP）管理器 |
| 443 | https | 安全超文本传输协议（HTTP） |
| 444 | snpp | 小型网络分页协议 |
| 445 | microsoft-ds | 通过 TCP/IP 的服务器消息块（SMB） |
| 464 | kpasswd | Kerberos 口令和钥匙改换服务 |
| 468 | photuris | Photuris 会话钥匙管理协议 |
| 487 | saft | 简单不对称文件传输（SAFT）协议 |
| 488 | gss-http | 用于 HTTP 的通用安全服务（GSS） |
| 496 | pim-rp-disc | 用于协议独立的多址传播（PIM）服务的会合点发现（RP-DISC） |
| 500 | isakmp | 互联网安全关联和钥匙管理协议（ISAKMP） |
| 535 | iiop | 互联网内部对象请求代理协议（IIOP） |
| 538 | gdomap | GNUstep 分布式对象映射器（GDOMAP） |
| 546 | dhcpv6-client | 动态主机配置协议（DHCP）版本6客户 |
| 547 | dhcpv6-server | 动态主机配置协议（DHCP）版本6服务 |
| 554 | rtsp | 实时流播协议（RTSP） |
| 563 | nntps | 通过安全套接字层的网络新闻传输协议（NNTPS） |
| 565 | whoami | whoami |
| 587 | submission | 邮件消息提交代理（MSA） |
| 610 | npmp-local | 网络外设管理协议（NPMP）本地 / 分布式排队系统（DQS） |
| 611 | npmp-gui | 网络外设管理协议（NPMP）GUI / 分布式排队系统（DQS） |
| 612 | hmmp-ind | HMMP 指示 / DQS |
| 631 | ipp | 互联网打印协议（IPP） |
| 636 | ldaps | 通过安全套接字层的轻型目录访问协议（LDAPS） |
| 674 | acap | 应用程序配置存取协议（ACAP） |
| 694 | ha-cluster | 用于带有高可用性的群集的心跳服务 |
| 749 | kerberos-adm | Kerberos 版本5（v5）的“kadmin”数据库管理 |
| 750 | kerberos-iv | Kerberos 版本4（v4）服务 |
| 765 | webster | 网络词典 |
| 767 | phonebook | 网络电话簿 |
| 873 | rsync | rsync 文件传输服务 |
| 992 | telnets | 通过安全套接字层的 Telnet（TelnetS） |
| 993 | imaps | 通过安全套接字层的互联网消息存取协议（IMAPS） |
| 994 | ircs | 通过安全套接字层的互联网中继聊天（IRCS） |
| 995 | pop3s | 通过安全套接字层的邮局协议版本3（POPS3） |
扩展知识
- 根据查询相关公开信息
- 第三次握手的时候，是可携带数据载荷的
- 一次、第二次握手不可以携带数据。原因是第一次握手不可放数据，其中一个简单的原因就是会让服务器更加容易受到攻击了。
- 而对于第三次，此时客户端已经处于ESTABLISHED状态。对于客户端来说，已经建立起连接了，并且也已经知道服务器的接收、发送能力是正常的了，能携带数据的。
UDP
UDP (User Datagram Protocol)协议为运用程序之间的消息发送提供了最小开销的协议机制。UDP是传输层协议，没有重传机制，不保障传输的可靠性。
UDP报文格式
| 端口号码 / 层 | 名称 | 注释 |
| 67 | BOOTP | BOOTP (Boot Protocol) |
| 123 | NTP | 网络时间协议NTP协议应用于分布式时间服务器和客户端之间，实现客户端和服务器的时间同步，从而使网络内所有设备的时钟基本保持一致。 |
| 161 | SNMP | 代理进程接收请求信息&NMS与代理进程之间的通信 |
| 162 | SNMP | NMS接收通知信息 |
| 520 | RIP | RIP通过UDP报文进行路由信息的交换 |
| 639 | MSDP-Source-Active | MSDP Source-Active消息用于携带多组（S，G）信息，在多个RP之间传递，或者封装PIM-SM组播数据。 |
| 1701 | L2TP | L2TP的控制消息和数据消息使用相同的报文头。L2TP报文头中标记为可选（opt）的字段，是指在数据消息中可选，在控制消息中则是必选的。 |
| 3784 | BFD | BFD单跳检测 |
| 4784&3784 | BFD | BFD多跳检测 |
| 4789 | VxLAN | 虚拟扩展局域网 |
| 6343 | sFlow | 采样流sFlow（Sampled Flow）是一种基于报文采样的网络流量监控技术，主要用于对网络流量进行统计分析。 报文格式 |
1192
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
