<计算机网络>运输层

端口号:通常在一台主机上运行多个网络应用程序,IP地址标识一台主机,而端口号标识特定的进程。端口是一个16bits的数,其大小在0-65535之间。0-1023之间的端口号叫做周知端口号

套接字:从网络向进程传递数据和从进程向网络传递数据的门户。是同一台主机内 应用层和运输层之间的接口,

一个UDP套接字是由一个两元组全面标识的。该二元组包含一个目的IP地址和一个目的端口号。如果两个UDP报文段有不同的源IP地址或者源端口号,但是具有相同的目的IP地址和目的端口号。那么它们仍然会通过相同的套接字定位到相同的目的进程。

多路分解:将运输层报文段中的数据交付到正确的套接字的工作。

多路复用:从源主机不同的套接字中收集数据块,并为其增加头部信息生成报文段。

UDP:

可能使用UDP的情形:

  1. 无需建立连接
  2. 应用层能够更好的控制发送的数据和时间(TCP拥塞时会遏制发送方发送)
  3. 无连接状态(TCP需要保持连接状态,包括接收,发送缓存,拥塞控制参数和序号和确认数的参数)
  4. 分组首部开销小(TCP头部大小20字节,UDP8字节)

UDP报文报文结构

net-3-1

UDP头部共8字节:四个字段,每个字段两字节。

检验和:提供了差错检测功能。用于确定当UDP报文段从源到达目的地移动的时候,其中的比特是否发生了变化。提供检验和的原因是不能保证源和目的之间的所有链路都提供差错检测。并且有可能报文段在路由的过程中引入比特差错。因而UDP必须在端到端的基础上在运输层一共差错检测。

可靠数据传输:

  1. rdt1.0:完全可靠信道上的可靠数据传输
  2. rdt2.0,2.1,2.2:具有比特差错信道上的可靠数据传输。引入了自动重传协议(ARQ),它需要另外三种协议来处理存在的比特差错。差错检测;接收方反馈(肯定恢复ACK和否定回复(NCK));重传(接受方有差错的分组的时候,重传)。对于发送方,在等到ACK或者NCK的状态下,不能发送分组。这被称为停等协议。rdt2.0没有考虑到ACK和NCK也有可能受损。解决办法是:如果收到受损的ACK或者NCK,则重传一次分组。但是这样无法确定是一次新的分组还是重传的分组。解决办法是在分组中添加一个序号字段。接受方检验序号即可确定是重传的还是新发的。
  3. rdt3.0:除了比特受损之外,信号还会出现丢包。因而引入时间机制决定何时重传分组。

流水线可靠数据传输:rdt3.0是一个停等协议,性能受到很大影响,如果能一次发送多个分组,则性能很大提升

  1. 流水线:不以停等方式运行,允许发送方发送多个分组而无需等待确认。带来的影响如下:
  • 必须增加序号范围:因为每个输送中的分组必须有一个唯一的序号,也许有多个在输送中的未确认的报文。
  • 协议的发送方和接收方缓存多个分组
  • 解决差错恢复的方法:回退N步选择重传

2.回退N步:滑动窗口协议。

net-3-10

  • 发送方:超时重传已发送但没确认的分组。
  • 接收方:每接收到一个有序分组交付到上层,丢弃无序分组;累计确认收到的有序分组。

选择重传:一个单个分组的差错就可能引起GBN重传大量分组,许多分组根本没有必要重传。随着信道差错率的增加,流水线可能被这些没有必要重传的分组填满。

TCP:面向连接,提供全双工的服务,数据流可以双向,也可以点对点。

MSS():最大报文段长度。

net-3-14

序号:TCP的序号是数据流的字节数,不是分组的序号。表示该报文段数据字段是首字节的序号

确认号:确认号是第一个未收到的字节序号,表示希望接收到的下一个字节。

首部长度:通常选项字段为空,一般长度20字节。

标志字段:

  • ACK:指示确认字段中的值是有效的
  • RST,SYN,FIN:连接的建立与拆除
  • PSH:指示接收方立即将数据上交上层
  • URG:报文段中存在紧急的数据,

接受窗口:用于流量控制。

流量控制:某应用程序读取数据时相对缓慢,而发送方发送太多并且快,导致接收缓存溢出。流量控制就是用来进行发送速度和接收速度的匹配。

  • LastByteRead:接收方应用程序从接收缓存中读取的最后一个字节
  • LastByteRcvd:接收方应用程序接收到的最后一个应用程序。

防止内存溢出:应该保证LastByteRecv-LastByteRead<=RecvBuffer.

接收方计算RcvWindow:RcvWindow=RcvBuffer-(LastByteRecv-LastByteRead).然后将RcvWindow记录在TCP报文中。发送方轮流跟踪两个变量,LastByteRecv和LastByteRead,这两个变量的差就是已发送但未确认的分组。通过将其控制在RecvWindow之内,就可以实现流量控制。

连接管理:

3次握手:

net-3-16

  1. 客户端向服务端发送SYN报文段,不包含应用层数据。首部的一个标志位(即SYN比特)被置位,客户端随机化选择(避免攻击)一个起始序号x)
  2. 服务器为该Tcp连接分配tcp缓存和变量,返回一个SYNACK报文段,
  3. 客户机为该连接分配缓存和变量。返回一个对SYNACK报文段进行确认的报文段

如果客户端不发送ACK来完成三次握手,那么服务器将会终止该连接,释放资源。

如果B发送给A的SYN+ACK中途丢失,没有达到A,那么B会周期性的超时重传,直到收到A的确认为止。

如果A发送给B的SYN中途丢失,没有到达B,A发完ACK,单方面认为TCP为 Established状态,而B显然认为TCP为Active状态

  • 假定此时双方都没有数据发送,B会周期性超时重传,直到收到A的确认,收到之后B的TCP 连接也为Established状态,双向可以发包
  • 假定此时A有数据发送,B收到A的 Data + ACK,自然会切换为established 状态,并接受A的Data
  • 假定B有数据发送,数据发送不了,会一直周期性的重传SYN+ACK,直到收到A的确认为止。

4次挥手:

TCP连接的两个进程中任意一个都能终止该连接,连接关闭需要4步。假设客户端发起一个关闭请求:

net-3-17

  1. 客户端向服务端发送一个FIN报文
  2. 服务端返回一对FIN报文的确认报文
  3. 服务端发送一个FIN报文
  4. 客户端返回一个对FIN报文的确认报文

TIME-WAIT:

  1. 可靠的实现全双工连接的终止
  2. 等待迷途分组在网络中消失

拥塞控制:

  1. 端到端的拥塞控制:网络层没有为运输层提供显示支持
  2. 网络辅助的拥塞控制:网路层向发送方提供显示反馈。

TCP拥塞控制:由于IP层不向端系统提供显示的网络拥塞反馈,所以TCP必须使用端到端控制。而不是网络辅助拥塞控制。

TCP

TCP连接的两方都记录一个额外的变量:拥塞窗口(CongWin),它对一个TCP发送方能向网络中发送流量的速率进行了限制。特别是,在一个发送方中未被确认的数据量不会超过CongWin与RcvWindow中的最小值。

两个拥塞指示:3次冗余ACK,超时

TCP拥塞控制算法:

  1. 加性增,乘性减。
    • 缓慢增加CongWin,每个RTT增加1个MSS,线性增长(拥塞避免)
    • 乘性减发生丢包时,设置CongWin = CongWin/2(不低于1个MSS),从而控制发送速度
  2. 慢启动:TCP连接开始时,CongWin的初始值为1个MSS,指数型增长
  3. 对拥塞指示做出反应:
    • 3次冗余ACK:CongWin = CongWin/2,然后线性增加(拥塞避免)
    • 超时:CongWin被设置为1个MSS,然后指数增长,直到CongWin达到超时前的一半为止。
  4. Threshold(阈值):用于确定慢启动将结束并且拥塞避免将开始的窗口长度,初始化为一个很大的值,每当发送一个丢包时,会被设置为丢包时CongWin的一半

net-3-19

猜你喜欢

转载自www.cnblogs.com/tingweichen/p/10693161.html