5.4—5.5 TCP与应用协议¶
本页要点：用字节序号理解可靠传输；区分接收窗口与拥塞窗口；区分HTTP资源、请求与连接；记端口时同时记传输协议和例外。IP地址与路由在计算与分析。
5.4.1 TCP、UDP和端口¶
TCP（Transmission Control Protocol，传输控制协议）提供可靠、按序、无重复的双向字节流，连接失败时仍可能报错，不能保证任意故障下必送达。它不保留写入消息边界，例如两次写入“AB”“CD”，对端可能一次读到“ABCD”，应用需用长度或分隔符定界。UDP（User Datagram Protocol，用户数据报协议）保留数据报边界，基础协议不提供确认重传、排序、接收窗口及拥塞控制；应用可以在其上实现这些机制，QUIC就是例子，因此UDP业务不等于没有可靠性。
TCP最小首部20 B，含可选字段时更长；UDP首部8 B。TCP目的/源端口各16 bit，配合IP与协议识别通信端点；已建立TCP连接通常由源IP、源端口、目的IP、目的端口区分。服务器443可同时服务很多连接，不能照抄“端口不可复用”；是否允许相同地址端口重复绑定还受操作系统选项限制。
TCP首部关键字段（基本首部20 B，可选项按数据偏移标明长度，首部总长最大60 B）：
| 字段 | 作用与读法 |
|---|---|
| 源端口、目的端口 | 各16 bit，标识两端应用端点；与IP地址共同区分连接 |
| 序号、确认号 | 各32 bit；序号标本段首字节，确认号在ACK有效时表示下一个期待字节 |
| 数据偏移 | 4 bit，以32 bit字为单位表示TCP首部长度；最小5、最大15（20—60 B） |
| 保留位、标志位 | 保留位发送时按规范置零；标志说明连接/数据状态，常见含义见下表 |
| 窗口 | 16 bit接收窗口字段；协商窗口缩放后有效通告值可更大，见§5.4.3 |
| 校验和 | 覆盖TCP首部、数据及IP伪首部，用于检错；不是加密或纠错码 |
| 紧急指针 | 仅URG有效时解释紧急数据边界；现代应用较少使用 |
| 选项与填充 | MSS、窗口缩放、SACK许可/块、时间戳等；填充使首部对齐32 bit边界 |
常见控制标志：SYN用于同步初始序号并建立连接；ACK表明确认号字段有效；FIN表示发送方完成发送并请求有序关闭该方向；RST复位拒绝或中止连接；PSH提示接收端尽快把已缓存数据交给应用，不保留应用消息边界；URG使紧急指针有意义。ECE/CWR用于ECN拥塞通知协商/反馈，具体过程取决于ECN配置。标志组合按状态机解释，例如握手第二段为SYN+ACK；不能仅凭某一标志断定业务数据已被应用处理。
| 服务 | 常见默认端口与传输 | 条件/例子 |
|---|---|---|
| FTP | TCP21控制；主动模式传统数据源端口TCP20 | 被动数据端口由服务端协商，不固定20 |
| SSH／Telnet | TCP22／23 | SSH提供安全远程终端，Telnet明文 |
| SMTP／POP3／IMAP | TCP25／110／143 | SMTP传送邮件，后两者取信；提交587和隐式TLS端口另有用途 |
| DNS | UDP53及TCP53 | 常规查询常走UDP，截断重试/区域传送等用TCP；不能说只UDP |
| DHCPv4 | UDP67服务端、68客户端 | 获取地址与租期等配置 |
| HTTP／HTTPS | 常见TCP80／443；HTTP/3常用UDP443 | URL可显式改端口，不由端口单独证明安全 |
| SNMP／Trap | 常见UDP161／162 | 轮询管理／主动告警 |
| NTP／Syslog | 常见UDP123／514 | 时间同步／日志；安全传输和厂商实现另有选择 |
| 数据库与桌面 | MySQL TCP3306、Oracle监听TCP1521、Redis TCP6379；RDP3389 | 产品默认可改，不能用端口猜测代替识别 |
端口表按手册及常用约定整理；非逐项查IANA的“完全核实”表，具体产品默认、TLS扩展和RDP传输详见核查表待核实项。
5.4.2 建连与关闭¶
sequenceDiagram
participant C as 客户端／主动关闭方
participant S as 服务端
C->>S: SYN seq=x
S->>C: SYN ACK seq=y ack=x+1
C->>S: ACK seq=x+1 ack=y+1
Note over C,S: 双方进入已建立状态后传数据
C->>S: FIN seq=u
S->>C: ACK ack=u+1
Note over S: 仍可发送尚未完成的数据
S->>C: FIN seq=v
C->>S: ACK ack=v+1
Note over C: TIME_WAIT 等待2MSL图N3按时间向下读，两个方向有独立序号空间，SYN和FIN各占一个序号，纯ACK不占。三次握手同步初始序号并防止旧连接请求误建；关闭时两个方向分别结束，因此常见四个报文，但ACK与FIN可合并，并非强制四包。TIME_WAIT便于重发最后ACK并让旧报文消散，不是证明某个ACK必然已经到达；同时关闭时双方也可能进入TIME_WAIT。
首部seq是本段首字节号，ack=N表示N之前已连续收到，下一期待N。例如seq=1001、长1000 B覆盖1001—2000，对应ack=2001。后续3001—4000先到而2001—3000缺失时，累计ACK仍为2001；SACK（选择确认）可另报已收非连续块，不能使累计ACK越过缺口。
超时重传定时器RTO根据RTT（往返时间）及波动估计，超时一般指数退避；ACK丢失后若更大的累计ACK及时到达，不必重传。经典快速重传通常要求3个重复ACK，不是任意重复一次就触发；重传沿用原字节序号，不计作新业务数据。
完整例：丢段、累计确认与窗口推进¶
连接已建立，客户端SYN序号1000，首数据从1001开始；MSS=1000 B，rwnd=4000 B、cwnd=3000 B，接收方缓存合格失序数据，忽略延迟ACK，仅B丢失。
| 步骤 | 数据与反馈 | 发送方/接收方状态 |
|---|---|---|
| 1 | 连发A、B、C各1000 B | A覆盖1001—2000、B覆盖2001—3000、C覆盖3001—4000；SND.UNA=1001、SND.NXT=4001，在途3000 B，不能新增发送 |
| 2 | A到达，ACK=2001；B丢失 | SND.UNA=2001，B/C仍有2000 B未累计确认；为突出恢复，本例此时不追加数据 |
| 3 | C到达缓存，仍ACK=2001 | 缺口未补，仅1个重复ACK，不够经典3重复ACK快速重传门槛 |
| 4 | RTO到期重传B：seq=2001、长1000 B | 沿用原序号，SND.NXT仍4001；本例经典超时处理令cwnd=1 MSS、RTO退避 |
| 5 | B补齐，B/C按序交付，ACK=4001 | SND.UNA=SND.NXT=4001，在途归零，累计确认一次跨过两段 |
| 6 | 明确给定此时cwnd=2000 B、rwnd=1000 B | 可新增min(1000,2000)−0=1000 B，由流控限制；该窗口值并非所有超时恢复的固定结论 |
| 7 | 发D：seq=4001、长1000 B；回ACK=5001 | 发送后在途1000 B，确认后归零，共4000 B有效数据，重传B不使有效量变5000 B |
SND.UNA为最早未确认位置，SND.NXT为下一新数据位置；本例无回绕，FlightSize=SND.NXT−SND.UNA。累计ACK前移会释放重传缓存，但不保证接收窗口变大；ACK仅证明对端TCP接收，不证明应用已处理或持久化。若D的ACK丢失且无更大ACK，D可能重发，接收端不重复交付。
5.4.3 流量、拥塞和工程限制¶
接收窗口rwnd保护接收缓存，拥塞窗口cwnd约束网络在途量。简化模型中可新增发送量为 max(0,min(rwnd,cwnd)−FlightSize)，FlightSize为尚未确认的在途字节量。例如rwnd=4000、cwnd=3000、已在途2000 B，只能新增1000 B，不能再发3000 B。rwnd为0时用窗口探测避免更新丢失形成永久等待，不表示连接关闭。
经典Reno式慢开始在理想逐段确认模型下约每RTT翻倍，达慢开始门限后转为约每RTT增加1个MSS（最大报文段数据长度）的拥塞避免；三重复ACK触发快速重传/快速恢复，超时则更保守。初始cwnd并非永远1 MSS，现代算法也并非统一减半，不能把教学曲线当所有产品实现。
窗口字段16 bit，最大未缩放值65535 B；窗口缩放需握手协商，适应高带宽高RTT路径。TCP发送能力还受BDP（带宽时延积）约束：链路速率R乘往返时延RTT得到理想填满路径所需的在途bit数；接收窗口和拥塞窗口都小于BDP时，发送端可能因窗口而无法填满路径。公式、单位换算和数值样例见计算与分析题 §带宽时延积，本页不重复算例。实际发送窗口仍受min(rwnd,cwnd)、未确认数据量、丢包和协议开销影响；窗口达到BDP不是吞吐必达链路速率的保证。Nagle算法在存在未确认小段时抑制继续发小段，延迟ACK可能与它叠加增加延迟；关闭与否需测量，不应当作通用调优口诀。短连接可能积累TIME_WAIT，可优先复用连接并核对端口范围与负载；不推荐不加条件地缩短等待时间。SYN Flood冲击半连接资源，SYN Cookie等机制可缓解，但不代替限流与容量规划。
5.5.1 HTTP语义与版本¶
HTTP（Hypertext Transfer Protocol，超文本传输协议）规定请求响应的语义。HTTP/1.1请求行如GET /logo.png HTTP/1.1，响应状态行如HTTP/1.1 200 OK；消息体可用Content-Length或协议允许的其他机制定界，不能依TCP一次读取结束判断响应结束。无状态是协议不强制保存上一请求业务状态，Cookie、令牌与Session仍可维持登录。
GET取表示，HEAD取对应首部，POST请求资源处理所带内容，PUT通常创建/替换目标表示，DELETE请求删除关联；幂等是重复请求的预期效果相同，不是每次响应相同，GET/PUT等语义也不等于自动安全。
| 状态码 | 如何读 | 小例子 |
|---|---|---|
| 200 | 成功，含义依方法 | GET取得图片 |
| 301/302 | 重定向 | Location指向新位置，重放方法须按规范/客户端行为处理 |
| 304 | 条件请求可复用缓存 | 不带新的表示消息体 |
| 400/401/403/404 | 请求错误／需认证／拒绝／未找到 | 收到404说明HTTP已响应，不等于TCP失败 |
| 500/502/503 | 内部错误／网关上游问题／暂不可用 | 查代理日志与上游健康，而不是只换网线 |
| 版本 | 承载与工作方式 | 队头阻塞及条件 |
|---|---|---|
| HTTP/1.0 | 通常TCP，默认非持久 | 部分实现有Keep-Alive扩展，不是绝不复用 |
| HTTP/1.1 | TCP，默认持久连接，管线化按序响应 | 多资源不等于一请求，响应按序会阻挡后续 |
| HTTP/2 | TCP，二进制帧、多流、HPACK头压缩 | 流交错但TCP丢包会阻挡同连接后续字节；推送能力不等于浏览器必启用 |
| HTTP/3 | QUIC（基于UDP），集成TLS1.3 | 独立流避免跨流的TCP重传阻塞；流内可靠排序仍会等缺失数据 |
HTTP/3不是“没有任何队头阻塞”，QPACK头部依赖、共享拥塞等仍可能造成等待。0-RTT需要已有可恢复的安全状态且服务端接受，存在重放风险，不是首次访问无条件零往返；连接迁移取决于协商和网络条件，不保证换网永不断线。以上边界以RFC9114为主，0-RTT安全细节还需配合QUIC/TLS规范。
打开网页例子：首次无缓存访问同源HTML及图片，明确采用HTTP/1.1 over TLS且顺序复用：DNS解析→TCP握手→TLS验证证书并协商密钥→GET HTML→解析引用→GET图片。取得2个资源、2次请求，可只用1条TCP连接；TCP段数无法由请求数确定。HTTP/3应改按QUIC流程分析，不能再先套TCP握手。
网页完整计数补充：上述例请求/index.html，Host: example.com指目标主机；HTML响应Content-Length: 1200只计消息体、不含首部/TLS/TCP/IP开销，解析出外链/logo.png后再请求图片。若图片响应体4096 B，仍按消息定界分别读取，不能由两次响应推TCP段数或TLS记录数。图片404时HTML仍可显示；有效缓存可能免去请求或经304复用表示。HTTP/2/3帧格式不能套HTTP/1.1文本行格式。HTTPS保护路径、查询参数、首部及消息体，但普通DNS、未受ECH保护的SNI等仍可能暴露域名。
5.5.2 TLS、名称与配置服务¶
HTTPS通过TLS提供传输机密性、完整性和对端认证能力，常见只验证服务端证书，双向证书需另配置。验证信任链、域名、有效期等后，才能确认连接到相应认证端点；它不保证网站诚实或数据库安全。TLS终止于反向代理时代理能看明文，代理到源站是否加密需另查；IP、流量大小和时间等元数据也不会全部隐藏。
DNS（Domain Name System，域名系统）中A/AAAA给IPv4/IPv6，CNAME给规范名称，MX给邮件交换器，NS给权威服务器，PTR作反向映射。客户端请求本地解析器代为求最终结果通常是递归；解析器自己问根、顶级域、权威服务器通常是迭代，缓存命中可省去其中步骤。递归/迭代与正向/反向是不同维度。
DHCP（Dynamic Host Configuration Protocol，动态主机配置协议）用发现Discover、提供Offer、请求Request、确认ACK完成常见DORA流程，租期内按规则续租。可配置IP、掩码、网关、DNS及多类选项；不能把回忆版“不可能下发邮件服务器”作通用结论，RFC2132 §8.14明确SMTP服务器列表为选项69，§8.15还定义POP3服务器选项70；是否配置和被客户端采用须看实现。RARP（反向地址解析）按MAC找自身IPv4，主要是早期启动机制，不能提供DHCP式完整配置。
RARP历史例：无盘工作站只知道网卡MAC为08-00-2B-01-02-03，广播请求，服务器查静态映射返回192.168.1.20；它不是向远端转发数据的选路机制，传统请求依赖本地广播域内服务器。DNS题若说“本地DNS代客户端向根查询”，要分清角色：对客户端承担递归，对根的单次交互通常为迭代。
FTP（File Transfer Protocol，文件传输协议）分控制连接与数据连接；主动模式由服务器主动连客户端协商端口，被动模式由客户端连服务器协商的数据端口，因此防火墙规则不能只放TCP20便断言FTP数据必通。
5.5.3 应用接口与持续通信（补充）¶
REST是架构风格：客户端/服务端、无状态、可缓存、统一接口、分层系统以及可选按需代码。无状态例如每次请求都带必要令牌，并不禁止服务端存业务数据。GraphQL由客户端选择字段，如只请求姓名减少过取，但查询复杂度与授权仍需控制。gRPC常用HTTP/2与Protocol Buffers表达强类型RPC（远程过程调用），适合内部服务；WebSocket常经HTTP/1.1 Upgrade建立双向持久消息通道，HTTP/2/3另有扩展连接机制，不能概括成所有版本都执行相同升级握手。
资料依据¶
手册PDF物理19—20页5.4—5.5；回忆版2022题59、60、63、68、69、93（9—10、13页），2024题59—61（21页）。本次实际访问：RFC9293 TCP、RFC9114 HTTP/3；其支持TCP语义、建连关闭与HTTP/3承载边界。另实际读取RFC9110 §9/§15核对方法、幂等及本页常用状态码，RFC1034 §4.3.1核对递归/非递归响应，RFC1035 §3.2.2/§4.2核对基本记录与UDP/TCP53，RFC2131 §3.1和RFC2132 §8.14核对DHCP流程与邮件服务器选项。完整端口表、TLS具体认证要求、应用接口定义仍有待核项；当前已读结论和未核边界见外部记录及核查表。