降低了IP层的效率 根据对方给出的窗口值和当前网络的拥塞的程度决定一个报文段应包含多少个字节

1）

UDP一次交付一个完整的报文。
应用程序需要选择合适的大小的报文。
若报文太长，UDP把它交给IP层后，IP层在传送时可能要进行分片，这会降低IP层的效率。
反之，若报文太短，UDP把它交给IP层后，会使IP数据报的首部的相对长度太大，这也降低了IP层的效率。

 

 

 UDP是面向报文的

 

 UDP用户数据的首部和伪首部

 

 2）

TCP不关心应用进程一次吧多长的报文发送到TCP的缓存中，而是
根据对方给出的窗口值和当前网络的拥塞的程度决定一个报文段应包含多少个字节
（UDP发送的报文长度是应用进程给出的）。
如果应用进程传送到TCP缓存的数据块太长，TCP就可以把它划分短一些再传送。
如果应用进程一次只发来一个字节，TCP也可以积累足够多的字节后在构成报文段发送出去。

 

TCP报文段的首部格式

 

3）未按序收到的

暂存在接收窗口

 

 

I
发送窗口
已发送并收到确认

已发送但未收到确认
允许发送但尚未发送

不允许发送

II
接收窗口
已发送确认并交付主机
未按序收到
允许接收
不允许接收

 

 

发送方
发送窗口内的序号都已用完，但还没有再收到确认，可用窗口减小到零，须停止发送。

如果接收方的确认都滞留在网络中，则发送方经过由超时计时器控制的一段时间后
就重传这部分数据；并重新设置超时计时器，直到收到接收方 的确认为止。

 

 发送方收到新的确认号，发送窗口向前滑动

 

TCP的缓存和窗口的关系

 

 

发送方的应用进程把字节流写入TCP的发送缓存，

接收方的应用进程从TCP的接收缓存中读取字节流。

发送缓存：

1、发送应用程序传送给发送方TCP准备发送的数据；

2、TCP已发送出但尚未收到确认的数据。

接收缓存：

1、按序到达的、但尚未被接收应用程序读取的数据；

2、为按序到达的数据。

如果收到的分组被检测出有差错，则要丢弃。

如果接收应用程序来不及读取收到的数据，接收缓存最终就会被填满，使接收窗口减小到零。

反之，如果接收应用程序能够及时从接收缓存中读取收到的数据，接收窗口就可以增大，但最大不能超过接收缓存的大小。

流量控制：flow control 让发送方的发送速率不要太快，要让接收方来得及接收。
利用可变窗口进行流量控制举例

 

ACK表示首部确认位

ack表示确认字段的值

 

抓包分析实践： 关注80和59371端口  ，练习计算序列号、确认号

 TCP连接的建立

 

 

 

同步位SYN=1 （建立连接）

初始序号seq

确认号ack

LISTEN 收听状态

SYN-SENT 同步已发送

SYN-RCVD 同步收到

ESTABLISHED 已建立连接

RFC 973

three way (three message) handshake 三报文握手

handshake 单数，不是复数，表明只是一次握手

 

TCP连接的释放

终止控制位FIN=1

主动方

FIN-WAIT-1 终止等待1

FIN-WAIT-2 终止等待2

TIME-WAIT 时间等待

被动方

CLOSE-WAIT 关闭等待

LAST-ACK 最后确认