网络复习-运输层

网络复习-运输层

---

• 网络层主要是主机到主机间的通信，而运输层是进程到进程间的通信。
  复用：所有的进程都可以通过运输层再传送到IP层。
  分用：运输层从IP层接收到数据后必须交付指明的应用进程。
  运输层主要有2种协议：TCP/UDP
  当数据到达某个主机时，使用协议端口号来查找指定进程，协议端口号一般是16位的。
  所以，在运输层，除了指定IP地址，还要指明端口号，也就是 IP + 端口号。

• 因特网上的计算机通信是使用 客户-服务器 的方式，因此端口号也分为2类：
  1.服务端使用的端口号：
  1).熟知端口号：
  范围0~1023，指派给一些重要的应用程序，让所有的用户都知道，比如 FTP进程相关的使用21端口号，HTTP进程相关的使用80端口号，DNS进程相关的使用53端口号，TELNET进程相关的使用23端口等。
  2).登记端口号：
  范围1024~49151，为没有指定端口号的进程使用。
  2.客户端使用的端口号：
  范围49152~65535，称为短暂端口号，在一次通信结束后就不复存在了，可供其他进程重复使用。

UDP

特点

1.无连接。
2.尽最大努力交付。
3.面向报文。对于进程交付下来的数据报，只添加首部后就向下交付到ip层，一次交付一整个报文。
4.没有拥塞控制。因此，在发送拥塞时也不会使源主机的发送速率降低，这很适合即时应用，比如聊天和视频。
5.支持多对多。
6.报文的首部开销小。

报文的首部格式

1.源端口。源IP地址是附给IP层时IP层的工作。
2.目的端口。目的IP地址在IP层附上。
3.长度。记录数据报的长度。
4.校验和。检测传输中是否有错，有错丢弃。

TCP

TCP的特点

1.TCP是面向连接的运输层协议，有三个步骤：建立连接、传输数据、释放连接。
2.TCP是可靠交付的，即无差错、不丢失、不重复、按序到达。
3.TCP是全双工通信。
4.TCP 只能是点对点的。这种点称为 套接字 （由IP地址 ： 端口号组成，端口号为16位），TCP连接则是有2个套接字组成。
5.面向字节流的。流指的是流进进程或者从进程中流出的字节序列。

TCP可靠传输的工作原理

因为IP层提供的是不可靠传输，因此可靠传输在TCP层实现。实现可靠传输主要是要解决２点：
１.传输信道不产生差错；
２.发送方的发送速度无论多快，接收方总是来得及处理收到的数据。

停止等待协议（ARQ）

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

• 出现发送数据丢失时，必要的特点：
  １.如果发送方发送数据后没有收到确认，就进行超时重传，也就是说发送方在收到确认前要保存好分组的副本；
  ２.需要按序发送和确认，意味着分组需要进行编号；
  ３.超时计时器设置的超时重传时间应当比数据在分组传输的平均往返时间更长一些。

超时重传时间的选择：
在实际的网络中，往返时间是很难确定的。提供2种常用方法
1.自适应算法：TCP保留了RTT的一个加权平均往返时间。
2.Karn算法：在自适应算法的基础上，将超时重传的报文段的往返时间不计入加权平均往返时间的采样中。

• 出现确认数据丢失时，必要的特点：
  １.如果确认丢失，那么发送方进行超时重传，接收方就会接收到重复的数据，这时要丢弃重复的数据；
  ２.再一次向发送方发送确认数据。

• 出现确认数据迟到时，必要的特点：
  1.如果确认延迟了，其实和丢失是一样的，当超时计时器到时，发送方就重传数据；
  2.这时接收方就会收到重复的数据，丢弃就行了，然后重新发送确认数据；
  3.过了延时时间后，当发送方接收到延时的确认时，丢弃就行了，此时应该收到过一份确认数据的了。

连续ARQ协议

1.发送方维持一个发送窗口，接收方也维持一个接收窗口；
2.发送方连续的发送数据而不需要等待一个个的确认，数据的量在窗口指定的值内；
3.接收方连续的接收数据，采用累积确认，然后对按序到达的最后一个分组发送确认。

TCP报文段的首部格式（部分重要的）

1.源端口、目的端口。
2.序号。某数据段的起始序号。
3.确认号。即从该序号指定的编号起至之前的数据都已经确认收到了，也提示希望收到的下一段的起始序号。
4.数据偏移。实际上指出报文段的首部长度。
5.紧急URG。值为1时，表示该报文段应尽快传送，无需按序，配合另一个参数一起使用，也就是紧急指针。多用在强行关闭。
6.确认ACK。值为1时，才表示确认号有效，也就是确认号的开关。
7.推送PSH。值为1时，表示无需等待缓存满了再发送出去，而是直接发送。
8.复位RST。值为1时，表明TCP连接中出现严重错误，必须释放连接，然后再重新建立连接。也用来拒绝一个非法报文段或拒绝打开一个连接。
9.同步SYN。用于请求连接的，请求方SYN=1，ACK=0，表示请求连接，而方式方SYN=1，ACK=1，表示允许连接。
10.终止FIN。用于释放连接的，当发送方FIN=1，表示此报文段的发送数据已经发送完毕了，并要求释放运输连接。
11.窗口。某一方的发送数据里的窗口指的是，告诉对方自己的接收窗口，也就是在确认号指定的序号开始，到最多多少序号的数据是自己能来得及接收的。

缓存
实际上，进程和窗口之间还存在一个缓存，缓存也才是窗口的调整依据。
1.在接收方，当进程在缓存里读取的速度变慢时，意味着缓存里的数据变多了，剩余空间变少了，那么就要调整接收窗口的大小，并通知对方。
2.在发送方，如果缓存快要满了，发送应用程序必须控制写入缓存的速率；发送窗口和发送缓存的后沿是重合的。

TCP的流量控制

1.发送方的发送数据量是依据接收方的返回的确认报文段中指定的接收窗口值。
2.当指定的接收窗口值为0时，双方处于暂停状态。
3.当接收方的缓存又有空闲时，发送新的确认报文段，并指定新的接收窗口值。

• 可能造成死锁：当3中，发送的报文段出现丢失时，发送方就会持续的等待非零窗口的通知，而接收方也会等待发送方发送数据。
  解决方法：当某一方接收到零窗口报文段时，就启动一个持续计时器，当计时到时，就发送一个零窗口探测报文段。假如对方还没有缓存空闲，那么此时还是会收到一个零窗口报文段通知，那么就重新置0持续计时器；假如是出现非零窗口通知丢失，那么等于是重新要求对方发送非零窗口的报文段，这样就有可能解决死锁了。

TCP的拥塞控制

拥塞控制和流量控制是不同的。
1.流量控制主要是要控制好在接收方所能接收的范围内，发送方的发送速度，对象是端；
2.而拥塞控制主要是要控制过多的数据注入到网络中，导致路由器或链路过载，对象是通道。

慢开始和拥塞避免

1.慢开始指的是发送方从很小量的数据报文段开始发送，每过一次就按2的平分指数增加发送的报文段数量，当到达ssthresh值之后就停止该操作；
2.到达ssthresh值后，就开始使用拥塞避免算法，也就是接下来报文段的量按照线性增长的方法增加；
3.当到达拥塞窗口指定的值后，就将ssthresh的值设为拥塞窗口（会根据网络情况进行改变的）指定的值的一半，然后重新从很小量的数据报文段开始执行慢开始方法，也就是重复1的操作。
总结为乘法减小，加法增大。

快重传

对于上诉方法，如果对于某个报文段没有按时抵达，就会被认为是可能出现了拥塞，那么会重新使用慢开始方法；而使用快重传，就是当某个报文段没有按时抵达时（接收检测到编号没有连续），接收方会在接下来的3次接收中，重复地回复没有按时抵达的报文段的前一个报文段的编号，由此让发送方快速地发送没有抵达的丢失报文段，而不必为丢失的报文段设置超时重传计时器。也就是说，原本的话，当某个报文段丢失时，发送方会启动一个超时重传计时器，等待指定报文段的确认，而现在不用了，让数据的传递一直下去，一旦收到某个报文段的3次重复确认，就表明这个报文段的下一个报文段可能丢失了，那么就赶紧重新发送那个报文段。

快恢复

快恢复就是在慢开始和拥塞避免的基础上进行改进。当拥塞避免到达拥塞窗口指定的值时，不用重新开始慢开始算法，而是在将ssthresh值变为拥塞窗口值的一半后，在新的ssthresh值处开始拥塞避免算法。

发送窗口的上限值 = Min [ rwnd接收窗口, cwnd拥塞窗口 ]，也就是取2者中小的一个。

TCP的运输连接管理

主动发起连接请求的进程称为客户端，被动等待连接的进程称为服务器。

三次握手

1.服务器进程先创建传输控制块TCB，准备接收客户进程的连接请求。
2.客户进程创建传输控制模块TCB。
3.第一次握手：客户端进程发送连接请求，进入SYN-SENT状态。SYN=1，seq=客户端初始序号，没有携带数据，消耗一个初始序号。
4.第二次握手：服务器进程发送同意连接的回复，进入SYN-RCVD状态。SYN=1，seq=服务器初始序号，没有携带数据，消耗一个初始序号；ACK=1，表示后面的ack生效；ack=客户端进程初始序号+1，表示收到连接请求了。
5.第三次握手：客户端进程发送确认给服务器，进入ESTAB-LISHED状态。ACK=1，表示后面的ack生效；seq=x+1，这里可以携带数据了；ack=服务器初始序号+1，表示收到同意请求的回复了。
6.服务器收到确认后进入ESTAB-LISHED。

第三次握手的必要

为了防止失效的连接请求造成服务器的资源浪费。考虑这种情况，当客户端发送的连接请求由于网络状况差而延迟到达服务器，在此之前客户端进程已经选择了不连接服务器端，而如果没有第三次握手，那么此时服务器在收到连接请求后就建立连接了，那么由于客户端进程已经放弃连接了，因此没有向服务器发送数据，而服务器进程则会浪费资源地在等待客户进程发送数据。所以第三次握手是必须的，当服务器进程发送同意连接请求后，如果收不到客户进程的确认，就知道了客户进程放弃了连接，可以不用等待客户进程的答应了，因此避免了资源浪费。

四次挥手

1.第一次挥手：客户端进程发送结束连接的请求，进入FIN-WAIT-1状态。FIN=1，表示此连接的发送数据已经发送完毕了；seq=客户进程前面已传送过的数据的最后一个字节的序号+1，至少消耗一个序号，表示请求断开的信息。
2.第二次挥手：服务器进程收到结束请求后，发送回一个确认，进入CLOSE-WAIT状态，发送最后的剩余数据。ACK=1，表示后面的ack有效；seq=服务器进程前面已传送过的数据+1；ack=客户进程seq值+1，表示收到了结束请求。
3.客户进程接收到回复后，就进入FIN-WAIT-2状态。此时还在持续接收来自服务器进程的剩余数据。
4.第三次挥手：服务器进程发送完最后的数据，发送断开连接的请求，进入LAST-ACK状态。FIN=1，表示此连接的发送数据已经发送完毕了；seq=最后剩余数据的最后一个字节序号；ACK=1，表示后面的ack值生效；ack=客户进程seq+1，这是重复的，上一次是表示对结束请求的确认，不过将发送最后的剩余数据，需要客户进程等待，这一次表示没有剩余数据需要发送的确认。
5.第四次挥手：客户端进程发送回一个对剩余数据的确认，进入TIME-WAIT状态。ACK=1，表示后面的ack生效；seq=自己请求结束连接的字节序号+1，表示答复断开的信息；ack=服务器进程发送的最后剩余数据的最后一个字节序号（也就是上一步里的seq）+1，表示收到了最后的数据段。
6.客户端进程维持一个大于往返时间的2MSL时间的等待，提防最后的确认没有到达服务器，导致服务器的重传。计时到了就重新发送确认。
7.服务器接收到确认后进入CLOSED状态，比客户端先进入该状态。
8.经过2MSL时间的等待后，如果没有接收到服务器的超时重传，就进入CLOSED状态。

第四次挥手的必要

如果没有第四次挥手，也就是说，在服务器发送完最后的数据后就断开连接了，那么当最后的数据丢失的情况下，就没有措施弥补了，有第四次挥手的话，可以保证最后的数据能够正常的抵达客户端。

保活计时器：每当服务器进程接收到一个数据时，就重置它，当计时器到时时，就发送一个探测报文段，如果一连10次探测报文段都没有响应，就关闭连接。它的作用是预防客户进程在与服务器进程建立连接后，发生了故障，而导致服务器白白等待的情况。