计算机网络传输层简介

作用：传输层是面向数据传输的最高层，而面向用户功能的最低层；在OSI七层参照模型中，传输层为应用层提供传输服务。

 

传输层与网络层的区别：网络层是对不同主机提供通信服务；传输层是对不同主机的不同进程(应用)提供通信服务；但是网络层只对数据报头进行无差错检查；传输层会对整个数据包进行无差错检测

功能：提供了复用和分用两个功能。 复用：在发送端多个应用程序使用同一个传输层。分用：在接受端传输层根据端口号把数据传输给相应的进程。

UDP

特点

UDP是在IP报文上添加了一些简单的功能：复用和分用、对报文的差错检测。

UDP是无连接性：UDP在使用前不需要连接，使用之后也不需要释放连接。

UDP是不可靠的：UDP的传输没有对接收端是否收到检查，所以在传输过程中不能确保每一个数据都能送达

UDP传输是面向报文的

面向报文：UDP传输是以报文为单位，但是他在传输过程中不会对报文做任何操作(裁剪、拼接)。 在发送端：应用程序给传输层什么数据，UDP传输过程中只在数据前面添加UDP报头，其他不做任何修改。在接收端：网络层给传输层的UDP后，UDP只去除报头不做任何修改将数据传给相应的进程(进程)。

UDP没有拥塞控制：UDP报文发送始终按照一个恒定的速率发送，不会根据网络拥塞的状况改变发送速率。

弊：网络拥塞可能导致报文丢失，所有UDP不可靠的

利：在有些地方允许数据报文丢失。例如需要低延迟的即时通讯的应用UDP就派上用场

UDP可以一对一、一对多、多对一、多对多通讯

TCP只能一对一通讯

UDP的首部开销比较小，只有8个字节

TCP最少也需要20个字节，相对来说UDP的开销就小得很多。

UDP的不可靠体现在几个方面

UDP是无连接性，客服端向服务端发送数据时不会知道服务端的状态，会导致数据丢失

客服端发送请求数据时，服务器端应答可能会导致数据丢失

由于通讯前双方的处理能力未知和UDP没有流量控制。有可能过载传输数据导致接收方的数据缓冲区溢出导致数据丢失。

UDP结构图

 

 

TCP

特点

TCP是具有连接性的：TCP在使用前必须建立连接，使用结束后需要释放连接

TCP提供可靠的交付服务：TCP在传输过程中的数据：无重复、无丢失、无差错，顺序和原来的一样

TCP面向字节流：TCP传输是以字节为单位，虽然在传输过程中数据被划分为几个数据报，这也是为了传输方便，传输后的数据和原来的数据保持不变

TCP提供全双工通信。TCP的两端既可以做发送端也可以做接收端

一条TCP两端只能用两个端点：tcp是提供点到点服务的

TCP报文结构图

 

 

源端口号和目的端口号：传输层和网络层的根本区别就是，传输层将数据传送到具体的应用，所有需要提供端口号。

序号和确认序号：序号指当前IP数据报数据部分的第一字节的序号。确认序号是指当前主机接受到信息后，期望下一条的数据编号是多少

标识符 ：TCP有7种标识符，用于表示TCP报文的性质。它们只能为0或1。

URG=1

当URG字段被置1，表示本数据报的数据部分包含紧急信息，此时紧急指针有效。

紧急数据一定位于当前数据包数据部分的最前面，紧急指针标明了紧急数据的尾部。

如control+c：这个命令要求操作系统立即停止当前进程。此时，这条命令就会存放在数据包数据部分的开头，并由紧急指针标识命令的位置，并URG字段被置1。

 

ACK=1

ACK被置1后确认号字段才有效。

此外，TCP规定，在连接建立后传送的所有报文段都必须把ACK置1。

 

PSH=1

当接收方收到PSH=1的报文后，会立即将数据交付给应用程序，而不会等到缓冲区满后再提交。

一些交互式应用需要这样的功能，降低命令的响应时间。

 

RST=1

当该值为1时，表示当前TCP连接出现严重问题，必须要释放重连。

 

SYN=1

SYN在建立连接时使用。

当SYN=1，ACK=0时，表示当前报文段是一个连接请求报文。

当SYN=1，ACK=1时，表示当前报文段是一个同意建立连接的应答报文。

 

FIN=1

FIN=1表示此报文段是一个释放连接的请求报文

 

接受窗口大小：该字段实现用于TCP的流量控制

检验和：用于检验整数据报是否出错

选项字段：可有可无，所以TCP最短是20最长是60.

TCP连接与套接字

TCP连接：是一个抽象的概念表示一条可以通信的链路。每条tcp通讯链路只用有两个点，表示通讯双方

套接字：TCP通讯的两端就是两个套接字。套接字=（IP地址：IP端口号）

 三次握手

 

 

第一次握手：客服端主动向服务器端发送连接请求，发送的报文段是：SYN=1，seq=x。发送完数据后客户端进入SYN-SENT状态，等待服务器端的确认信息

第二次握手：服务器段收到客户端的连接请求并且同意连接，发送的报文段是：SYN=1，ACK=x，seq=y，ack=x+1。服务器端进入SYN_RCVD状态

第三次握手：客户端收到服务器端的同意请求，再一次的向服务器端发送确认信息，报文段有：ACK=1，seq=x+1，ack=y+1，客户端进入established状态

为什么建立连接是三次握手而不是两次握手

防止失效的请求被服务器接收，产生错误。

 

说明：如果建立连接是两次握手，那么客户端没有什么变化，在得到服务器端的确认后就进入了ESTABLISHED状态。而服务器端在发送完确认信息就进入到了ESTABLISHED状态。如果在网络拥塞的情况下，客户端发送的连接请求(连1),因为网络拥塞导致连1不能送到服务器端，然后客服端超时重发连2，然而连2很快到达服务器端后，进行了连接。但是在他们连接结束，释放后连接后。那么现在连1到了，由于是两次握手，那么服务器端直接进入ESTABLISHED状态，等待客户端方发送消息，但是客户端已经关闭了，那么服务器端就会一直等待下去，造成资源浪费。

 

四次挥手

 

 

第一次挥手：客户端主动发送释放连接请求，报文段 FIN=1，seq=u，然后客服端进入FIN-WAIT-1状态。

第二次挥手：服务器端收到信息，向客户端发送释放应答并且服务器的应用通知程序会通知该连接已经被断开，报文信息：ACK=1，seq=v，ack=u+1，发送完报文后于是进入CLOSE-WAIT状态。

第三次挥手：服务器端主动发起断开请求，报文信息 FIN=1，ACK=1，seq=w，ack=u+1，客户端收到消息后进入TIME-WAIT状态。

第四次挥手：客户端向服务器端发送收到确认信息，报文内容:ACK=1,seq=u+1,ack=w+1,服务器端进入CLOSE状态。

为什么最后客户端要进入TIME_WAIT状态

为了确保B能够收到A的消息

 

如果A不进入TIME_WAIT状态，而是直接结束，那么第四次握手发送的报文由于网络拥塞，没有发送到服务器端服务器由于超时重发，但是此时的客户端已经关闭，那么服务器端会一直等待信息，就不会正常关闭了。

 

TCP的可靠传输是怎么实现的

TCP的可靠性表现在：tcp发送给程序的数据，无丢失，无损坏，无重复，有序。一句话来说就是：TCP发送给程序的最终数据和发送者最开始发送的数据时一摸一样的。

 

TCP的可靠性：TCP的流量控制，拥塞控制，连续的ARQ技术来保证的。

 

停止等待协议(ARQ)

TCP保证其可靠性使用的是更为复杂的滑动窗口协议，然而停止等待协议是他的简化版，我们这儿先介绍停止等待协议。

 

ARQ

ARQ(Automatic Repeat reQuest)自动重传请求

 

停止等待协议：当请求失败时，就会自动重传，知道请求被确认为止。这种机制可以保证每个分组都能被处理。停止等待协议也是一样ARQ协议。

 

停止等待协议原理

无差错情况：A每向B发送一个请求后都要停止发送，直到等待确认应答，A只有收到B的应答后才发送下一个请求。

分组丢失和出现差错情况

发送者都会有一个超时计时器，每发送一个分组就开始计时，等待B应答，如果B超时没有应答，那么A就会重新发送直到能收到应答为止。

 

分组出现差错：如果B收到的分组经过检查出现错误，那么直接将该分组扔掉，等待发送者超时重发。

 

分组丢失：若分组在途中丢失，B并没有收到分组，因此也不会有任何响应。当A超时后也会重传分组，直到正确接收该分组的应答为止。

综上所述：当分组丢失 或 出现差错 的情况下，A都会超时重传分组。

 

应答丢失 和 应答迟到 的情况

TCP会给每个字节都打上序号，用于判断该分组是否已经接收。

应答丢失：若B正确收到分组，并已经返回应答，但应答在返回途中丢失了。此时A也收不到应答，从而超时重传。紧接着B又收到了该分组。接收者根据序号来判断当前收到的分组是否已经接收，若已接收则直接丢弃，并补上一个确认应答。

应答迟到：若由于网络拥塞，A迟迟收不到B发送的应答，因此会超时重传。B收到该分组后，发现已经接收，便丢弃该分组，并向A补上确认应答。A收到应答后便继续发送下一个分组。但经过了很长时间后，那个失效的应答最终抵达了A，此时A可根据序号判断该分组已经接收，此时只需简单丢弃即可。

 

停止等待协议的注意点

每发送完一个分组，该分组必须要被保留，直到确认该分组已经被接收了才不需要保留

必须给每个分组进行编号。以便按序接收，并判断该分组是否已被接收。

必须设置超时计时器。每发送一个分组就要启动计时器，超时就要重发分组。

计时器的超时时间要大于应答的平均返回时间，否则会出现很多不必要的重传，降低传输效率。但超时时间也不能太长

 

 

滑动窗口协议（连续ARQ协议）

连续ARQ协议

在ARQ协议发送者每次只能发送一个分组，在应答到来前必须等待。而连续ARQ协议的发送者拥有一个发送窗口，发送者可以在没有得到应答的情况下连续发送窗口中的分组。这样降低了等待时间，提高了传输效率。

 

累计确认

在连续ARQ协议中，接收者也有个接收窗口，接收者并不需要每收到一个分组就返回一个应答，可以连续收到分组之后统一返回一个应答。这样能节省流量。

TCP头部的ack字段就是用来累计确认，它表示已经确认的字节序号+1，也表示期望发送者发送的下一个分组的起始字节号。

 

 

 

连续ARQ的注意点

 

同一时刻发送窗口的大小并不一定和接收窗口一样大。

虽然发送窗口的大小是根据接收窗口的大小来设定的，但应答在网络中传输是有时间的，有可能t1时间接收窗口大小为m，但当确认应答抵达发送者时，接收窗口的大小已经发生了变化。

此外发送窗口的大小还随网络拥塞情况影响。当网络出现拥塞时，发送窗口将被调小。

 

TCP标准并未规定未按序到达的字节的处理方式。但TCP一般都会缓存这些字节，等缺少的字节到达后再交给应用层处理。这比直接丢弃乱序的字节要节约带宽。

 

TCP标准规定接收方必须要有累计确认功能。接收方可以对多个TCP报文段同时确认，但不能拖太长时间，一般是0.5S以内。

此外，TCP允许接收者在有数据要发送的时候捎带上确认应答。但这种情况一般较少，因为一般很少有两个方向都要发送数据的情况。

 

流量控制

什么是流量控制？

如果发送者发送过快，接收者来不及接收，那么就会有分组丢失。为了避免分组丢失，控制发送者的发送速度，使得接收者来得及接收，这就是流量控制。

 

流量控制的目的？

流量控制根本目的是防止分组丢失，它是构成TCP可靠性的一方面。

 

如何实现流量控制？

由滑动窗口协议（连续ARQ协议）实现。

滑动窗口协议既保证了分组无差错、有序接收，也实现了流量控制。

 

流量控制引发的死锁

当发送者收到了一个窗口为0的应答，发送者便停止发送，等待接收者的下一个应答。但是如果这个窗口不为0的应答在传输过程丢失，发送者一直等待下去，而接收者以为发送者已经收到该应答，等待接收新数据，这样双方就相互等待，从而产生死锁。

 

持续计时器

为了避免流量控制引发的死锁，TCP使用了持续计时器。每当发送者收到一个零窗口的应答后就启动该计时器。时间一到便主动发送报文询问接收者的窗口大小。