Faii Note

type

status

date

slug

summary

传输层协议

进程之间通信

只有主机才有传输层+以上，传输单位为报文段

功能：

提供进程与进程之间的逻辑通信

复用和分用：同时发送，接收后分发

差错检测

可靠信道+不可靠信道

主要协议

传输控制协议TCP，传送数据前建立连接，不提供广播服务

用户数据报协议UDP，传送数据前不需要建立连接，不需要确认

传输层端口

复用：应用进程都可以通过传输层再传送到 IP 层（网络层）

分用：传输层从 IP 层收到发送给应用进程的数据后，必须分别交付给指明的各应用进程

问题：如何指明唯一的进程 → 端口

端口号：在传输层使用协议端口号（只有本地意义）

TCP/IP传输层端口标志：16位端口号，允许65535个不同的端口号

服务器端口

熟知端口：TCP/IP重要应用程序使用的固定端口号 0-1023
登记端口：其他应用程序 1024-49151

客户端端口

短暂端口：短暂端口，通信结束后收回 49152-65535

套接字唯一标识了网络中的一个主机和它上面的一个进程

用户数据报协议UDP

UDP概述

UDP只在IP的数据报服务上增加了

复用分用

差错检测

主要特点

无连接

不保证可靠交付

面向报文：一次传输一个完整的报文

按照应用层报文，添加UDP首部直接发送
应用程序需要选择合适大小的报文（太长IP层需要分片，太短降低IP层效率）

没有拥塞控制

支持广播（一对多，多对一

首部开销小（只有8个字节，TCP首部20个字节）

首部格式

UDP基于端口的分用：接收方 UDP 根据首部中的目的端口号，把报文通过相应的端口上交给应用进程，如果目标端口号不正确，则丢弃

在计算校验和时，会临时在数据报前添加12字节的伪首部（源IP，目的IP，0，17，UDP长度）

注意，校验和首部和数据都校验（求和运算）

传输控制协议TCP

TCP特点

TCP是面向连接的传输层协议

每一条TCP只有两个端点（点对点，一对一）

提供可靠交付

全双工通信 → 发送缓存+接收缓存

面向字节流：不关心报文长度，按字节流处理

TCP连接

TCP连接的端点：套接字（IP地址+端口号）

可靠传输的工作原理

IP提供不可靠、无连接的数据报传输服务。无可靠的意思是它不能保障IP数据报能成功的到达目的地。无连接这个术语的意思是IP并不维护任何关于后续数据报的状态信息。

停止等待协议

每发送完一个分组就停止发送，等待对方的确认。在收到确认后再发送下一个分组。

ACK确认信息

出现差错：

B 接收 M1 时检测出了差错，就丢弃 M1，其他什么也不做（不通知 A 收到有差错的分组）

M1 在传输过程中丢失了，这时 B 当然什么都不知道，也什么都不做。

A为每个已发送的分组设置超时计时器（超过时间就重发）

若ACK丢失，B接收重传数据，此时B操作：

丢弃重复分组，不向上层交付

向A发送确认

若ACK迟到，…

缺点：信道利用率太低

提高效率：流水线传输 → ARQ

连续ARQ协议

发送窗口：发送方维持一个发送窗口，位于发送窗口内的分组都可被连续发送出去，而不需要等待对方的确认。

发送窗口滑动：发送方每收到一个确认，就把发送窗口向前滑动一个分组的位置

累积确认：接收方对按序到达的最后一个分组发送确认，表示：到这个分组为止的所有分组都已正确收到了

注：TCP并不是每一个报文段都会回复ACK的，可能会对一个报文段发送一个ACK（M0、M2），也可能会对多个报文段发送1个ACK（M3+M4+M5）

Go-back-N回退n

TCP报文段首部格式

TCP 虽然是面向字节流的，但 TCP 传送的数据单元却是报文段

TCP 报文段首部的前 20 个字节是固定的，后面有 4n 字节是根据需要而增加的选项 (n 是整数)。因此 TCP 首部的最小长度是 20字节。

序号：占 4 字节。TCP 连接中传送的数据流中的每一个字节都有一个序号。序号字段的值则指的是本报文段所发送的数据的第一个字节的序号。

确认号：占 4 字节，是期望收到对方的下一个报文段的数据的第一个字节的序号（如已经发送了1 2 3，那返回的确认信息中确认号为4）

数据偏移（即首部长度）：占 4 位，

紧急URG 控制位：紧急数据段不会在发送缓存中排队

确认ACK ACK=1时确认号有效，否则确认号没有意义

推送PSH：当接收TCP收到PSH=1的报文段后，应该尽快交付应用进程，而不用缓存满了再交付

复位RST 同步SYN 终止FIN（结束连接）

窗口：从本报文段首部中的确认号算起，接收方目前允许对方发送的数据量。B发给A后A就知道自己的发送缓存要怎么设置（动态变化）

校验和：添加伪首部后和数据一起校验

紧急指针：本报文段中紧急数据的字节数（代表TCP数据中的紧急数据有多少）

MSS：最大报文段长度：TCP 报文段中的数据字段的最大长度

TCP可靠传输的实现

以字节为单位的滑动窗口

TCP的发送方和接收方分别维持一个发送窗口和接收窗口

发送窗口：在没有收到确认的情况下，发送方可以连续把窗口内的数据全部发送出去。凡是已经发送过的数据，在未收到确认之前都必须暂时保留，以便在超时重传时使用

接收窗口：只允许接收落入窗口内的数据。

累计确认方式可以看一下ppt的流程

去PPT看这里的流程

同时，缓存和窗口相关

发送缓存的大小可能会大于实际需要（最后写入cache的字节是实际对应位置）

绿色代表已接收，蓝色代表未接受

超时重传时间选择

TCP 发送方在规定的时间内没有收到确认就要重传已发送的报文段

TCP采用自适应算法，记录报文段发出时间和收到确认的时间（往返时间RTT

RTTs为加权平均往返时间

New RTTs = (1-a)Old RTTs + a New RTT

超时重传时间RTO应略大于RTTs

*冗余ACK：接到失序报文段时返回一个期待字节的ACK → 快速重传

TCP流量控制

滑动窗口实现流量控制

通信过程中，接收方根据自己接收缓存的大小动态调整发送窗口大小

直到接收窗口把窗口内部信息上传后，会发送一个新的ACK=1,ack=601,rwnd=400的确认信号，才可以再次发送

死锁情况：更新窗口信号丢失：TCP为连接设置持续计时器，只要 TCP 连接的一方收到对方的零窗口通知，就启动该持续计时器。

若到期则发送探测报文段，窗口仍然是0则计时器重启，否则结束死锁

TCP传输效率

糊涂窗口综合症？

TCP拥塞控制

拥塞控制原理

网络性能变差时，网络吞吐量下降，称为拥塞

出现拥塞条件：对资源需求的总和>可用资源

拥塞控制：防止过多数据注入到网络中（是全局性的问题-相对于流量控制，涉及所有主机路由器）

拥塞控制算法

TCP采用滑动窗口进行用拥塞控制，发送方维持一个拥塞窗口（动态变化）

真正的发送窗口值 = min（接收方通知窗口，拥塞窗口）

慢开始：由小到大逐渐增大拥塞窗口，直到慢开始门限，网络拥塞发生时重新回到慢开始窗口为1阶段

拥塞避免：让拥塞窗口缓慢增大，每经过一个RTT，拥塞窗口+1

快重传：发送方要尽早知道个别报文段的丢失（只要连续收到3个重复的确认，就立即重传）

快恢复：收到3个重复确认时不执行慢开始，而执行快恢复算法（不回到1，而是回到新的门限值（窗口/2)）

TCP传输连接管理

TCP连接三个阶段

连接建立

数据传送

连接释放

连接建立

三报文握手

发送SYN=1，seq=x（代表传输数据的第一个数据字节的序号，随机选择）

返回SYN=1，ACK=1，ack=x+1，seq=y（自己选择）

发送SYN=0，ACK=1，seq=x+1，ack=y+1

完成连接建立，可以进行数据传送

连接释放

四次挥手

客户端发送连接释放报文段：FIN=1，seq=u

服务器确认：ACK=1，seq=v，ack=u+1（服务器还可以传送一些数据，此时发送的数据用户仍需要接收）

服务器没有继续发送的数据，FIN=1，ACK=1，ack=u+1，seq=w

用户确认：ACK=1，ack=w+1，seq=u+1

等待时间等待计时器结束后释放TCP连接。

!这里看一下TCP的有限状态机