计网笔记3-运输层

3 运输层

两个协议TCP ， UDP
可靠性传输

TCP：分段，编号，流量控制，建立会话（QQ发文件）
UDP：一个数据包就能完成数据通信，不建立会话（QQ发消息），多播

运输层与应用层的关系：

• http=TCP+80
• https=TCP+443
• ftp=TCP+21
• SMTP==TCP+25
• POP3=TCP+110
• RDP=TCP+3389
• 共享文件夹=TCP+445
• SQL=TCP+1433
• DNS=UDP+53 or TCP+53（很少）

应用层和服务的关系（用端口来定位服务）：服务运行后再TCP或UDP的某个端口上侦听客户端的请求

• TCP是面向连接的传输层协议，可靠的
• 每一条TCP连接只能有两个端点（点对点）
• TCP提供可靠交付的服务
• 面向字节流

UDP：
特点：
1）无连接，即发送之前不需要建立连接，发送之后不需要断开连接，减少了开销和发送数据之前的时延。
2）不保证可靠交付（尽最大努力的）
3）面向报文
面向报文的传输方式是应用层交给UDP多长的报文，UDP就照样发送，即一次发送一个报文。
4) UDP没有拥塞控制，因此网络出现的拥塞不会使源主机的发送速率降低。
5) UDP支持一对一、一对多、多对一和多对多的交互通信。
6) UDP的首部开销小，只有8个字节，比TCP的20个字节的首部要短

3.1 TCP报文段的首部

• TCP 虽然是面向字节流的，但 TCP 传送的数据单元却是报文段。
• 一个 TCP 报文段分为首部和数据两部分，而 TCP 的全部功能都体现在它首部中各字段的作用。
• TCP 报文段首部的前 20 个字节是固定的，后面有 4n 字节是根据需要而增加的选项 (n 是整数)。因此 TCP 首部的最小长度是 20 字节。
  
• 源，目的端口：发送的端口起点和终点，每个2字节
• 序号：表示TCP数据部分是整个文件的第多少个字节，用于接收方拼装成文件，及查验漏包等
• 确认号： 接收方回复时，在确认号中写上次接收到文件的最后一个字节数+1（累加确认方式，收到多个时回复最后一个），方便发送方发送后续文件（既回复了确认消息，也让发送方知道这次该从那开始发）
• 数据偏移：记录TCP报文段的第多少个字节是数据，四个字节，最大15，标识第数据偏移值*4个字节，所以首部最长60字节，可变地方最长40字节
• 保留：6个字节，未使用
• 标记位：共六位，每位一个作用
  • URG：若标记为1，则这个数据部分在缓冲中可以插队，提前发送（例：取消发送文件时使用，将TCP数据报URG置1插队放在前面先发给接收方，接收方就立即停止接收，而不用等缓冲区的东西先发完再停止）
  • ACK：标识确认号是否有效，为0时表示确认号无效，为1表示确认号有效（例：建立会话时，发起方一般置0，回复方置1 ）
  • PSH：若为1，接收方收到后，直接放到接收方缓冲区的首部，让接收方提前从缓冲区拿出来（不然接收方拿数据是按照先到先拿的方式）
  • RST：为1表示异常中断（发送方停止发送时使用，直接停止传输）
  • SYN：发请求通讯建立连接时，一般置1（来回都是1）
  • FIN：数据发送完时，本位置1，表示传输结束，释放连接
• 检验和：用于首部的数据检验
• 紧急指针：紧急数据在尾部结束的位置

双方通信期间，双方都会告诉对方自己的接收缓冲区大小，从而建立一个和对面接收缓冲区一样大的发送缓冲区，使的双方的通信可以正常进行。

3.2 TCP协议如何实现可靠传输

传输方式：

1.停止等待：发送一个就等待对方回信，确认后发送第二个包

• 可靠确认方式
  • 超时重传：发送方在指定时间内没有收到接收方的确认消息，就会重发数据
  • 确认丢失：发送方指定时间内未收到接收方发回的确认消息，发送方就会重发，接收方如果接收到重复的数据就会丢弃
  • 确认迟到：接收方发回的消息卡在路上，过了发送方等待指定时间，导致发送方已经重发消息并收到了确认后之前的确认才到，这时发送方会收下这个确认但不对这个确认做回应。
• 缺点：信道利用率很差，一般不使用

2.流水线传输：不等待接收方回复，一直发数据

• 可靠确认方式
  • 逐个确认：稳定，丢包及时发现并重发，但每个包都要回复确认，效率较低
    • 发送方一次维护n个发送窗口，假设现在要发送m个数据报（M>>n）
    • 一次性发送前n个数据，并等待回复
    • 当第一个数据收到回复后发送第n+1个数据，收到第k个数据后再依次往后发送n+k个数据，直到发送完毕
  • 累加确认：确认次数减少，效率较高，但丢包补发时，需要批量补发，可能补发到接收方已经收到的包
    • 发送方一次维护n个发送窗口，假设现在要发送m个数据报（M>>n）
    • 一次性发送前n个数据，并等待回复
    • 发送方回复k表示收到了发送的1到k个数据（1<=k<=n）
    • 若k小于n，则表示第k+1个数据没收到，k+2到n个包不能确定是否收到了，此时发送方会把k+1到n的包全部补发（可能发接收方已经收到的包），直到收到回复n确认这批数据都收到了。

3.3 TCP协议如何实现流量控制

流量控制是端到端的控制，例如A通过网络给B发数据，A发送的太快导致B没法接收(B缓冲窗口过小或者处理过慢)，这时候的控制就是流量控制，原理是通过滑动窗口的大小改变来实现。
拥塞控制是A与B之间的网络发生堵塞导致传输过慢或者丢包，来不及传输。防止过多的数据注入到网络中，这样可以使网络中的路由器或链路不至于过载。拥塞控制是一个全局性的过程，涉及到所有的主机、路由器，以及与降低网络性能有关的所有因素。

流量控制机制：
以字节为单位的滑动窗口

• 接收方与发送方分别维护一个缓冲区（要求发送方缓冲小于等于接收方缓冲区）
  • 使用一个窗口确定发送方可以发送范围，只要窗口范围内的数据还未发送过，发送方都能发出
  • 接收方收到数据后会给发送方回复确认消息
    • 若正常收到连续块，回复消息中确认号为连续块最后一个字节编号加1，让发送方接着发
    • 若接收断层了，比如收到了12，345，89，中间的67断掉丢失了，接收方会给发送方回复6表示，并附带消息标记中间丢失的部分，让发送方重发67.
  • 发送方每次收到接收方的确认消息，都会根据确认号，挪动窗口的相应位置，使得窗口内出现新的未发送字节。

超时重传时间的选择：略大于加权平均往返时间

设主机A向主机B发送数据。双方确定的窗口值是400.再设每一个报文段为100字节长，序号的初始值为seq=1,大写ACK表示首部中的却认为ACK，小写ack表示确认字段的值。
接收方的主机B进行了三次流量控制。第一次把窗口设置为rwind=300，第二次减小到rwind=100最后减到rwind=0，即不允许发送方再发送过数据了。这种使发送方暂停发送的状态将持续到主机B重新发出一个新的窗口值为止。
假如，B向A发送了零窗口的报文段后不久，B的接收缓存又有了一些存储空间。于是B向A发送了rwind=400的报文段，然而这个报文段在传送中丢失了。A一直等待收到B发送的非零窗口的通知，而B也一直等待A发送的数据。这样就死锁了。为了解决这种死锁状态，TCP为每个连接设有一个持续计时器。只要TCP连接的一方收到对方的零窗口通知，就启动持续计时器，若持续计时器设置的时间到期，就发送一个零窗口探测报文段（仅携带1字节的数据），而对方就在确认这个探测报文段时给出了现在的窗口值。

3.4 TCP协议如何避免网络拥塞

出现拥塞的条件：对资源需求的总和>可用资源
是全局性的过程，是所有主机和路由共同造成的。

拥塞控制：

3.4.1 慢开始算法

第一次发一个包，若不丢包，第二次发2个，若仍未出现丢包，再增加两倍，直到达到每次发的个数大于等于门限值（初值为16）时，则让发包数等于门限值。若仍未出现丢包，后面就每次增加一个包。直到发送包数量为n时出现丢包现象，此时设置门限值为n/2，并从每次1个包再次开始发，每次增加两倍直到要大于等于门限值时，就将发包数定位和门限值一样，并又开始采取逐个增加发包数的手段，直到再一次丢包。

慢开始算法并不能完全避免拥塞，只是在拥塞避免阶段把拥塞窗口控制为按线性规律增长，使网络不容易出现拥塞。

3.4.2 快重传和快恢复

• 快重传
  • 发送方每次发送五个数据包，接收方就发一次确认
  • 接收方需要进行确认
    • 若五个都收到，回复时带上确认号，让发送方发接下来五个包
    • 若丢失了包，比如收到的是1.2.4，此时接收方就意识到3号数据包丢失了（可能要拥塞了），立即（收到4的时候）给发送方回复3次，确认号为3，让发送方重发3号数据包。（发三次的原因是让接收方判定网络是不是堵了，若三次都收到则网络应该没问题，若只收到1次或2次，或者没收到网络就出现了拥塞现象，为了避免拥塞此时执行快恢复算法）
• 快恢复
  • 快恢复的快是相对于慢开始的
  • 收到丢包确认后，将发包次数重n立即变为n/2，并开始逐个增加发包次数，直到再次丢包，不需要变为1再指数增长。

注：一次发包的数量就是发送窗口的上限值，这个值在不拥塞的情况下可以一直增加，但其实也是有上限的，上限值就是接受方的缓冲大小。

3.5 TCP的传输连接管理

三个阶段：连接建立、数据传送、连接释放。
TCP连接的建立都采用客户服务器方式，主动发起连接建立的应用进程是客户，被动等待连接建立的应用进程叫做服务器。

3.5.1 TCP的连接建立

使用三次握手建立TCP连接

• 1.客户向服务器发送同步数据包：SYN=1，ACK=0，seq=x（同步且确认号无效，序号是x），客户端从cLOSED状态变为SYN-SENT状态。
• 2.服务器回复同步数据包：SYN=1，ACK=1，seq=y，ack=x+1（同步且确认号有效，序号为y，确认号为x+1），服务器从CLOSED变为SYN-RCVD状态。
• 3.客户端回复：ACK=1，seq=x+1，ack=y+1（确认号有效，序号为x+1，确认号为y+1），发送后客户端和服务端都变为ESTABLISED状态

存在第三次握手的原因：防止已失效的连接请求报文段突然又到了B，从而产生错误。
比如：A给B之前发送的请求报文滞留在了路上，没发过去，于是A重新给B发送了请求报文并成功，此时之前滞留的请求报文又到了，于是发送了两次。此时B以为A又要建立新的连接，于是又发回了确认，但A又不理B，只认前面那次连接，但B为A多开了一个连接，并等待A发来数据，导致B的资源浪费。

3.5.2 TCP的连接释放

使用四次挥手释放连接，数据传输结束后，通信双方就可以释放连接。

• A向B发送TCP释放连接报文段，并停止传输数据，主动关闭TCP连接。（首部FIN=1，序号seq=u）等待B的确认。A从ESTABLISED状态变为EIN-WAIT-1状态
• B回复确认，（确认号ack=u+1，序号seq=v，ACK=1），TCP服务器进程通知高层，此时从A到B的通道就关闭了，但B到A的通道还开着（TCP连接半关闭状态），B若给A发数据，A仍然要接收。B从ESTABLISED状态变为EIN-WAIT状态，A变为EIN-WAIT-2状态
• 此时B向A发送TCP释放连接报文段（首部FIN=1，序号seq=w，ACK=1，ack=u+1），确认号依然按照A发送的释放连接的序号来决定.B变为LAST-ACK状态
• A回复确认（确认号ack=w+1，序号seq=u+1，ACK=1），此时B到A的通道也关闭，B收到回复后直接进入CLOSED状态，而A发送后进入TIME-WAIT状态，并在等待2msl（msl称为最长报文段寿命，是2分钟，所以需要等待四分钟）的时间后进入CLOSED状态（只有进入CLOSED状态才能开始下一次连接）

设置TIME-WAIT状态的原因：

• 最后回复给B的确认消息可能丢失，若在规定时间内，B没有收到确认信息，B会重新给A发送TCP释放连接报文段（首部FIN=1，序号seq=w，ACK=1，ack=u+1），此时的A需要重新回复，并重新开始2msl的倒计时。
• 经过时间2msl后，可以确保本连接持续时间内所产生的报文段全部消失，使得下一次开始时不会收到之前说过的“已失效的连接请求报文段”

保活计时器：确保客户端宕机后不会一直等待，超时（保活时间）后向客户端发送探测报文段，连续十个未回复，就主动切断连接。