计算机网络复习总结2

Posted 王嘻嘻-

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了计算机网络复习总结2相关的知识,希望对你有一定的参考价值。

1.10 介绍一下TCP三次握手。

  1. 第一次握手:建立连接,客户端发送syn包(syn=x)到服务器,并进入SYN_SENT状态,等待服务器确认;SYN:同步序列编号(Synchronize Sequence Numbers)。
  2. 第二次握手:服务器收到syn包,必须确认客户的SYN(ack=x+1),同时自己也发送一个SYN包(syn=y),即SYN+ACK包,此时服务器进入SYN_RECV状态;
  3. 第三次握手:客户端收到服务器的SYN+ACK包,向服务器发送确认包ACK(ack=y+1),此包发送完毕,客户端和服务器进入ESTABLISHED(TCP连接成功)状态,完成三次握手。

1.11 介绍一下TCP的四次挥手。

  1. 客户端进程发出连接释放报文,并且停止发送数据。释放数据报文首部,FIN=1,其序列号为seq=u(等于前面已经传送过来的数据的最后一个字节的序号加1),此时,客户端进入FIN-WAIT-1(终止等待1)状态。 TCP规定,FIN报文段即使不携带数据,也要消耗一个序号。
  2. 服务器收到连接释放报文,发出确认报文,ACK=1,ack=u+1,并且带上自己的序列号seq=v,此时,服务端就进入了CLOSE-WAIT(关闭等待)状态。TCP服务器通知高层的应用进程,客户端向服务器的方向就释放了,这时候处于半关闭状态,即客户端已经没有数据要发送了,但是服务器若发送数据,客户端依然要接受。这个状态还要持续一段时间,也就是整个CLOSE-WAIT状态持续的时间。
  3. 客户端收到服务器的确认请求后,此时,客户端就进入FIN-WAIT-2(终止等待2)状态,等待服务器发送连接释放报文(在这之前还需要接受服务器发送的最后的数据)。
  4. 服务器将最后的数据发送完毕后,就向客户端发送连接释放报文,FIN=1,ack=u+1,由于在半关闭状态,服务器很可能又发送了一些数据,假定此时的序列号为seq=w,此时,服务器就进入了LAST-ACK(最后确认)状态,等待客户端的确认。
  5. 客户端收到服务器的连接释放报文后,必须发出确认,ACK=1,ack=w+1,而自己的序列号是seq=u+1,此时,客户端就进入了TIME-WAIT(时间等待)状态。注意此时TCP连接还没有释放,必须经过2∗∗MSL(最长报文段寿命)的时间后,当客户端撤销相应的TCB后,才进入CLOSED状态。
  6. 服务器只要收到了客户端发出的确认,立即进入CLOSED状态。同样,撤销TCB后,就结束了这次的TCP连接。可以看到,服务器结束TCP连接的时间要比客户端早一些。

四次挥手过程

(1)客户端向服务器发送FIN控制报文段(首部中的 FIN 比特被置位);

(2)服务端收到FIN,回复ACK。服务器进入关闭等待状态,发送FIN;

(3)客户端收到FIN,给服务器回复ACK,客户端进入等待状态(进入“等待”,以确保服务器收到ACK真正关闭连接);

(4)服务端收到ACK,链接关闭。

1.12 为什么需要四次挥手?

TCP协议是一种面向连接的、可靠的、基于字节流的传输层通信协议。TCP是全双工模式,这就意味着,当客户端发出FIN报文段时,只是表示客户端已经没有数据要发送了,客户端告诉服务器,它的数据已经全部发送完毕了;但是,这个时候客户端还是可以接受来自服务端的数据;当服务端返回ACK报文段时,表示它已经知道客户端没有数据发送了,但是服务端还是可以发送数据到客户端的;当服务端也发送了FIN报文段时,这个时候就表示服务端也没有数据要发送了,就会告诉客户端,我也没有数据要发送了,之后彼此就会愉快的中断这次TCP连接。

简单地说,前 2 次挥手用于关闭一个方向的数据通道,后两次挥手用于关闭另外一个方向的数据通道。

1.13 三次握手为什么要有最后一次ACK?

证明了客户端的接收能力,与服务器端的发送能力。
客户端首先向服务器发送一个连接请求,但是可能这个连接请求走了远路,等了很长时间,服务器都没有收到,那么客户端可能会再次发送,此时服务器端收到并且回复SYN、ACK;在这个时候最先发送的那个连接请求到达服务器,那么服务器会回复一个SYN,ACK;但是客户端表示自己已经收到确认了,并不搭理这个回复,那么服务器可能陷入等待,如果这种情况多了,那么会导致服务器瘫痪,所以要发送第三个确认。

1.14 介绍一下TCP粘包、拆包的机制。

  1. TCP粘包和拆包问题

    TCP是一个“流”协议,所谓流,就是没有界限的一长串二进制数据,没有消息保护边界。一方发送的多个报文可能会被合并成一个大的报文进行传输,这就是粘包;也可能发送的一个报文,可能会被拆分成多个小报文,这就是拆包。

  2. 产生TCP粘包和拆包的原因

粘包的主要原因:

  1. 发送方每次写入数据 < 套接字(Socket)缓冲区大小;
  2. 接收方读取套接字(Socket)缓冲区数据不够及时;

半包 的主要原因:

  1. 发送方每次写入数据 > 套接字(Socket)缓冲区大小;
  2. 发送的数据大于协议的 MTU (Maximum Transmission
    Unit,最大传输单元),因此必须拆包;

其实我们可以换个角度看待问题:

从收发的角度看,便是一个发送可能被多次接收,多个发送可能被一次接收。
从传输的角度看,便是一个发送可能占用多个传输包,多个发送可能共用一个传输包。

根本原因是:TCP 是流式协议,消息无边界

扩展资料

UDP会不会产生粘包问题呢?

TCP为了保证可靠传输并减少额外的开销(每次发包都要验证),采用了基于流的传输,基于流的传输不认为消息是一条一条的,是无保护消息边界的(保护消息边界:指传输协议把数据当做一条独立的消息在网上传输,接收端一次只能接受一条独立的消息)。UDP则是面向消息传输的,是有保护消息边界的,接收方一次只接受一条独立的信息,所以不存在粘包问题。

举个例子:有三个数据包,大小分别为2k、4k、6k,如果采用UDP发送的话,不管接受方的接收缓存有多大,我们必须要进行至少三次以上的发送才能把数据包发送完,但是使用TCP协议发送的话,我们只需要接受方的接收缓存有12k的大小,就可以一次把这3个数据包全部发送完毕。

  1. 如何处理

如上所述,UDP 之所以不会产生粘包和半包问题,主要是因为消息有边界。因此,我们也可以采取类似的思路处理tcp消息。

  1. 改成短连接(不推荐)
    将 TCP 连接改成短连接,一个请求一个短连接。这样建立连接到释放连接之间的消息即为传输的信息,消息也就产生了边界。

优点:十分简单,不需要在我们的应用中做过多修改。
缺点:效率低下,TCP连接和断开都会涉及三次握手以及四次握手,每个消息都会涉及这些过程,十分浪费性能。

  1. 封装成帧
    将传输消息封装成帧(Framing),也就是原本发送消息的单位是缓冲大小,现在换成了帧,这样我们就可以自定义边界了。一般有以下4种方式:

固定长度 (不推荐)
消息长度采用固定长度即可,较短的消息可采用默认值填充。

优点:实现简单。 缺点:有极大的流量浪费,如果传递的消息中大部分都比较短,为了兼容最长的消息可能消息中有很多默认值作为无效的信息传输。

分隔符(消息体较短时,推荐)

使用分隔符作为消息边界,通过获取分隔符将消息切割。

优点:空间使用率高,实现也比较简单。
缺点:是当内容本身出现分割符时需要转义,所以无论是发送还是接受,都需要扫描整个内容做转义处理。

在特殊字符分隔符协议中:
发送方,需要在发送一个报文时,需要在报文尾部添加特殊分割符号;
接收方,在接收到报文时,需要对特殊分隔符进行检测,直到检测到一个完整的报文时,才能进行处理。
在使用特殊字符分隔符协议的时候,需要注意的是,我们选择的特殊字符,一定不能在消息体中出现,否则可能会出现错误的拆包。例如,发送方希望把”12\\r\\n34”,当成一个完整的报文,如果是按行拆分,那么就会错误的拆分为2个报文。一种解决策略是,发送方对需要发送的内容预先进行base64编码,由于base64编码只包含64个字符:0-9、a-z、A-Z、+、/,我们可以选择这64个字符之外的特殊字符作为分隔符。

  1. 专门的 length 字段

这种方式有点类似于Http 请求中的 Content-Length,有一个专门的字段存储消息的长度。作为服务端,接受消息时,先解析固定长度的字段(length字段)获取消息总长度,然后读取后续内容。

优点:精确定位用户数据,内容也不用扫描转义。
缺点:长度理论上有限制,因为长度字段占用字节数为固定值要先定义, 因此限制了传输消息的最大长度。另外如果长度占用字节过多,在传输短消息时,会造成头部信息占比过长,影响传输效率。

消息体较长时,推介用这种方式。

  1. 其他方式

其他方式多种多样,比如 JSON 可以看成是使用 是否成对,xml可以看括号是否配对等等。

1.15 介绍一下TCP和UDP的区别。

  1. 连接:TCP面向连接的传输层协议,即传输数据之前必须先建立好连接;UDP无连接。

  2. 服务对象:TCP点对点的两点间服务,即一条TCP连接只能有两个端点;UDP支持一对一,一对多,多对一,多对多的交互通信。

  3. 可靠性:TCP可靠交付:无差错,不丢失,不重复,按序到达;UDP是不可靠的。

  4. TCP是面向字节流的,UDP是面向数据报文的

  5. TCP协议下双方发送接受缓冲区都有,UDP并无实际意义上的发送缓冲区,但是存在接受缓冲区

  6. 拥塞控制/流量控制:有拥塞控制和流量控制保证数据传输的安全性;UDP没有拥塞控制,网络拥塞不会影响源主机的发送效率。

  7. 报文长度:TCP动态报文长度,即TCP报文长度是根据接收方的窗口大小和当前网络拥塞情况决定的;UDP面向报文,不合并,不拆分,保留上面传下来报文的边界。

  8. 首部开销:TCP首部开销大,首部20个字节;UDP首部开销小,8字节(源端口,目的端口,数据长度,校验和)。

  9. 适用场景(由特性决定):数据完整性需让位于通信实时性,则应该选用TCP 协议(如文件传输、重要状态的更新等);反之,则使用 UDP 协议(如视频传输、实时通信等)。

1.16 TCP和UDP对于网络稳定性有什么要求?

  1. TCP优缺点

    优点:可靠、稳定

    TCP的可靠体现在TCP在传输数据之前,会有三次握手来建立连接,而且在数据传递时,有确认、窗口、重传、拥塞控制机制,在数据传完之后,还会断开连接用来节约系统资源。

    缺点:慢,效率低,占用系统资源高,易被攻击

    在传递数据之前要先建立连接,这会消耗时间,而且在数据传递时,确认机制、重传机制、拥塞机制等都会消耗大量时间,而且要在每台设备上维护所有的传输连接。然而,每个链接都会占用系统的CPU、内存等硬件资源。因为TCP有确认机制、三次握手机制,这些也导致TCP容易被利用,实现DOS、DDOS、CC等攻击。

  2. UDP优缺点

    优点:快,比TCP稍安全

    UDP没有TCP拥有的各种机制,是一个无状态的传输协议,所以传递数据非常快,没有TCP的这些机制,被攻击利用的机制就少一些,但是也无法避免被攻击。

    缺点:不可靠,不稳定

    因为没有TCP的那些机制,UDP在传输数据时,如果网络质量不好,就会很容易丢包,造成数据的缺失。

  3. 适用场景(网络稳定性要求

    TCP:当对网络通讯质量有要求时,比如HTTP、HTTPS、FTP等传输文件的协议, POP、SMTP等邮件传输的协议

    UDP:对网络通讯质量要求不高时,要求网络通讯速度要快的场景。

    所以,TCP对网络稳定性要求高,而UDP相对弱一些。

1.17 如何让UDP可靠一些?

  1. 为什么需要可靠的UDP

    在弱网(2G、3G、信号不好)环境下,使用 TCP 连接的延迟很高,影响体验。使用 UDP 是很好的解决方案,既然把 UDP 作为弱网里面的 TCP 来使用,就必须保证数据传输能像 TCP 一样可靠。

  2. 如何实现可靠的UDP

    UDP它不属于连接型协议,因而具有资源消耗小,处理速度快的优点,所以通常音频、视频和普通数据在传送时使用UDP较多,因为它们即使偶尔丢失一两个数据包,也不会对接收结果产生太大影响。传输层无法保证数据的可靠传输,只能通过应用层来实现了。实现的方式可以参照tcp可靠性传输的方式,只是实现不在传输层,实现转移到了应用层。关键在于两点,从应用层角度考虑:

    (1)提供超时重传,能避免数据报丢失。

    (2)提供确认序列号,可以对数据报进行确认和排序。

    本端:首先在UDP数据报定义一个首部,首部包含确认序列号和时间戳,时间戳是用来计算RTT(数据报传输的往返时间),计算出合适的RTO(重传的超时时间)。然后以等-停的方式发送数据报,即收到对端的确认之后才发送下一个的数据报。当时间超时,本端重传数据报,同时RTO扩大为原来的两倍,重新开始计时。

    对端:接受到一个数据报之后取下该数据报首部的时间戳和确认序列号,并添加本端的确认数据报首部之后发送给对端。根据此序列号对已收到的数据报进行排序并丢弃重复的数据报。

扩展资料

已经实现的可靠UDP:

(1)RUDP 可靠数据报传输协议;

(2)RTP 实时传输协议:为数据提供了具有实时特征的端对端传送服务;

Eg:组播或单播网络服务下的交互式视频、音频或模拟数据

(3)UDT:基于UDP的数据传输协议,是一种互联网传输协议;

主要目的是支持高速广域网上的海量数据传输,引入了新的拥塞控制和数据可靠性控制机制(互联网上的标准数据传输协议TCP在高带宽长距离的网络上性能很差);

UDT是面向连接的双向的应用层协议,同时支持可靠的数据流传输和部分可靠的数据报服务;

应用:高速数据传输,点到点技术(P2P),防火墙穿透,多媒体数据传输;

1.18 TCP报文首部中序号占多少字节?

序号字段占4个字节(32位)。

TCP首部包括20字节的固定首部部分及长度可变的其他选项,所以TCP首部长度可变。20个字节又分为5部分,每部分4个字节32位,如图中的5行,每行表示32位。

  1. 源端口和目的端口字段——各占 2 字节(16位)。端口是传输层与应用层的服务接口。传输层的复用和分用功能都要通过端口才能实现。

  2. 序号字段——占 4 字节。TCP 连接中传送的数据流中的每一个字节都编上一个序号。序号字段的值则**指的是本报文段所发送的数据的第一个字节的序号。**比如分组的第一个数据包由文件的14个字节数据组成,那么该数据包所添加的序号就是1,同理第二个数据包由文件的59个字节数据组成,那么该数据包所添加的序号就是5;

  3. 确认号字段——占 4 字节,是期望收到对方的下一个报文段的数据的第一个字节的序号。比如接收端收到由文件14个字节数据+TCP首部组成的数据包后,删除首部提取14个字节数据,返回的确认号为5,即告诉发送端下一次应该发送文件的第5个字节及其之后字节组成的数据包过来。

  4. 数据偏移(即首部长度)——占 4 位,它指出 TCP 报文段的数据起始处距离 TCP 报文段的起始处有多远,也就是TCP首部的长度。“数据偏移”的单位是 32 位字(以 4 字节为计算单位),最大1111表示15x4=60个字节,即表示TCP首部最大长度为60个字节,因此“选项”部分最多40个字节。

  5. 保留字段——占 6 位,保留为今后使用,但目前应置为 0。

  6. 这里的六位二进制位,分别表示不同含义:

    (1)紧急 URG —— 当 URG = 1 时,表明紧急指针字段有效。它告诉系统此报文段中有紧急数据,应尽快传送(相当于高优先级的数据)。 即URG=1的数据包不用排队直接优先传输。

    (2)同步 SYN —— 同步 SYN = 1 表示这是一个连接请求或连接接受报文。即A想与B建立连接,发送过去的第一个数据包(第一次握手)中SYN=1;B返回的数据包(第二次握手)中SYN=1表示同意建立连接。

    (3)确认 ACK —— 只有当 ACK = 1 时确认号字段才有效。当 ACK = 0 时,确认号无效。

  7. 窗口字段 —— 占 2 字节,用来让对方设置发送窗口的依据,单位为字节。

  8. 检验和 —— 占 2 字节。检验和字段检验的范围包括首部和数据这两部分。在计算检验和时,要在 TCP 报文段的前面加上 12 字节的伪首部。

  9. 紧急指针字段 —— 占 16 位,指出在本报文段中紧急数据共有多少个字节(紧急数据放在本报文段数据的最前面)。

  10. 选项字段 —— 长度可变。TCP 最初只规定了一种选项,即最大报文段长度 MSS (Maximum Segment Size)是 TCP 报文段中的数据字段的最大长度。数据字段加上 TCP 首部才等于整个的 TCP 报文段。MSS 告诉对方 TCP:“我的缓存所能接收的报文段的数据字段的最大长度是 MSS 个字节。”其他选项有:窗口扩大选项、时间戳选项、选择确认选项(SACK)。

  11. 填充字段 —— 这是为了使整个首部长度是 4 字节的整数倍。

1.19 TCP中的缓存有什么作用?

  1. TCP缓冲区是什么

    每个 socket 被创建后,都会分配两个缓冲区,输入缓冲区和输出缓冲区。

  2. 缓冲区的意义(作用)

TCP的发送缓冲区是用来缓存应用程序的数据,发送缓冲区的每个字节都有序列号,被应答确认的序列号对应的数据会从发送缓冲区删除掉。

write()/send() 并不立即向网络中传输数据,而是先将数据写入缓冲区中,再由TCP协议将数据从缓冲区发送到目标机器。一旦将数据写入到缓冲区,函数就可以成功返回,不管它们有没有到达目标机器,也不管它们何时被发送到网络,这些都是TCP协议负责的事情。 TCP协议独立于 write()/send() 函数,数据有可能刚被写入缓冲区就发送到网络,也可能在缓冲区中不断积压,多次写入的数据被一次性发送到网络,比如nagle算法,这取决于当时的网络情况、当前线程是否空闲等诸多因素,不由程序员控制。 read()/recv() 函数也是如此,也从输入缓冲区中读取数据,而不是直接从网络中读取。

  1. I/O缓冲区特性

    (1)I/O缓冲区在每个TCP套接字中单独存在;

    (2)I/O缓冲区在创建套接字时自动生成;

    (3)即使关闭套接字也会继续传送输出缓冲区中遗留的数据;

    (4)关闭套接字将丢失输入缓冲区中的数据。

    输入输出缓冲区的默认大小一般都是 8K,可以通过 getsockopt() 函数获取:

    //代码实例(缓冲区大小获取) 
    int servSock = socket(PF_INET, SOCK_STREAM, 0); 
    unsigned optVal; 
    int optLen = sizeof(int); 
    getsockopt(servSock, SOL_SOCKET, SO_SNDBUF, (char*)&optVal, &optLen); 
    /*  运行结果:  Buffer length: 8192  */
    

1.20 说一说TCP是怎么控制流量的?

  1. 一般来说,流量控制就是为了让发送方发送数据的速度慢点,要让接收方来得及接收。

  2. TCP控制流量的方法

    利用滑动窗口机制就可以实施流量控制。

    原理就是运用TCP报文段中的窗口大小字段来控制,发送方的发送窗口不可以大于接收方发回的窗口大小。考虑一种特殊的情况,就是接收方若没有缓存足够使用,就会发送零窗口大小的报文,此时发送方将发送窗口设置为0,停止发送数据。之后接收方有足够的缓存,发送了非零窗口大小的报文,但是这个报文在中途丢失的,那么发送方的发送窗口就一直为零导致死锁。

    解决这个问题,TCP为每一个连接设置一个持续计时器(persistence timer)。只要TCP的一方收到对方的零窗口通知,就启动该计时器,周期性的发送一个零窗口探测报文段。对方就在确认这个报文的时候给出现在的窗口大小(注意:TCP规定,即使设置为零窗口,也必须接收以下几种报文段:零窗口探测报文段、确认报文段和携带紧急数据的报文段)。

  3. TCP的滑动窗口

    为了提高信道的利用率TCP协议不使用停止等待协议,而是使用连续ARQ(Automatic Repeat-reQuest,自动重传请求)协议,意思就是可以连续发出若干个分组然后等待确认,而不是发送一个分组就停止并等待该分组的确认。

    TCP的两端都有发送/接收缓存和发送/接收窗口。TCP的缓存是一个循环队列,其中发送窗口可以用3个指针表示。而发送窗口的大小受TCP数据报中窗口大小的影响,TCP数据报中的窗口大小是接收端通知发送端其还可以接收多少数据,所以发送窗口根据接收的的窗口大小的值动态变化。

    以下的几张图片就帮助理解一下滑动窗口的机制:

注意上图中的3个指针P1、P2、P3!此时接收窗口中接收的数据可能是失序的,但是也先存储在接收缓存之中。发送确认号的时候依然发送31,表示B期望接收的下一个数据报的标示符是31。

如果发送窗口中的数据报都属于已发送但未被确认的话,那么A就不能再继续发送数据,而需要进行等待。

  1. 传输效率及Nagle算法

    TCP的数据传输分为交互数据流和成块数据流,交互数据流一般是一些交互式应用程序的命令,所以这些数据很小,而考虑到TCP报头和IP报头的总和就有40字节,如果数据量很小的话,那么网络的利用效率就较低。

    数据传输使用Nagle算法,Nagle算法很简单,就是规定一个TCP连接最多只能有一个未被确认的未完成的小分组。在该分组的确认到达之前不能发送其他的小分组。

    但是也要考虑另一个问题,叫做糊涂窗口综合症。当接收方的缓存已满的时候,交互应用程序一次只从缓存中读取一个字节(这时候缓存中腾出一个字节),然后向发送方发送确认信息,此时发送方再发送一个字节(收到的窗口大小为1),这样网络的效率很低。

    要解决这个问题,可以让接收方等待一段时间,使得接收缓存已有足够的空间容纳一个最长报文段,或者等到接收缓存已有一半的空间。只要这两种情况出现一种,就发送确认报文,同时发送方可以把数据积累成大的报文段发送。

1.21 HTTP2.0中TCP阻塞了怎么办?

HTTP2.0中TCP阻塞了有如下两种方法可以解决:

(1)并发TCP连接(浏览器一个域名采用6-8个TCP连接,并发HTTP请求) (2)域名分片(多个域名,可以建立更多的TCP连接,从而提高HTTP请求的并发)

1. TCP队头阻塞

​TCP数据包是有序传输,中间一个数据包丢失,会等待该数据包重传,造成后面的数据包的阻塞。

2. HTTP队头阻塞

​ http队头阻塞和TCP队头阻塞完全不是一回事。

​ http1.x采用长连接(Connection:keep-alive),可以在一个TCP请求上,发送多个http请求。

​ 有非管道化和管道化,两种方式。

非管道化,完全串行执行,请求->响应->请求->响应…,后一个请求必须在前一个响应之后发送。

管道化,请求可以并行发出,但是响应必须串行返回。后一个响应必须在前一个响应之后。原因是,没有序号标明顺序,只能串行接收。

管道化请求的致命弱点:

(1)会造成队头阻塞,前一个响应未及时返回,后面的响应被阻塞
(2)请求必须是幂等请求,不能修改资源。因为,意外中断时候,客户端需要把未收到响应的请求重发,非幂等请求,会造成资源破坏。

​ 由于这个原因,目前大部分浏览器和Web服务器,都关闭了管道化,采用非管道化模式。

​ 无论是非管道化还是管道化,都会造成队头阻塞(请求阻塞)。

2. HTTP2方式

http2使用一个域名单,TCP连接发送请求,请求包被二进制分帧,不同请求可以互相穿插,避免了http层面的请求队头阻塞。 但是不能避免TCP层面的队头阻塞。

1.22 TCP如何保证可靠性?

TCP协议保证数据传输可靠性的方式主要有:校验和、序列号、确认应答、超时重传、连接管理、流量控制、拥塞控制、丢弃重复数据

流量控制是针对接收端接收能力的控制机制,

拥塞控制是针对当前网络的控制机制。

  1. 校验和

    计算方式:在数据传输的过程中,将发送的数据段都当做一个16位的整数。将这些整数加起来。并且前面的进位不能丢弃,补在后面,最后取反,得到校验和。 发送方:在发送数据之前计算检验和,并进行校验和的填充。 接收方:收到数据后,对数据以同样的方式进行计算,求出校验和,与发送方的进行比对。

注意:如果接收方比对校验和与发送方不一致,那么数据一定传输有误。但是如果接收方比对校验和与发送方一致,数据不一定传输成功。

  1. 序列号和确认应答

    序列号:TCP传输时将每个字节的数据都进行了编号,这就是序列号。
    确认应答:TCP传输的过程中,每次接收方收到数据后,都会对传输方进行确认应答。也就是发送ACK报文。这个ACK报文当中带有对应的确认序列号,告诉发送方,接收到了哪些数据,下一次的数据从哪里发。

序列号的作用不仅仅是应答的作用,有了序列号能够将接收到的数据根据序列号排序,并且去掉重复序列号的数据。这也是TCP传输可靠性的保证之一。

  1. 超时重传

    在进行TCP传输时,由于确认应答与序列号机制,也就是说发送方发送一部分数据后,都会等待接收方发送的ACK报文,并解析ACK报文,判断数据是否传输成功。如果发送方发送完数据后,迟迟没有等到接收方的ACK报文,这该怎么办呢?而没有收到ACK报文的原因可能是什么呢?

    首先,发送方没有接收到响应的ACK报文原因可能有两点:

    (1)数据在传输过程中由于网络原因等直接全体丢包,接收方根本没有接收到。

    (2)接收方接收到了响应的数据,但是发送的ACK报文响应却由于网络原因丢包了。

    TCP在解决这个问题的时候引入了一个新的机制,叫做超时重传机制。简单理解就是发送方在发送完数据后等待一个时间,时间到达没有接收到ACK报文,那么对刚才发送的数据进行重新发送。如果是刚才第一个原因,接收方收到二次重发的数据后,便进行ACK应答。如果是第二个原因,接收方发现接收的数据已存在(判断存在的根据就是序列号,所以上面说序列号还有去除重复数据的作用),那么直接丢弃,仍旧发送ACK应答。

  2. 连接管理

    连接管理就是三次握手与四次挥手的过程,保证可靠的连接,是保证可靠性的前提。

  3. 流量控制

接收端在接收到数据后,对其进行处理。如果发送端的发送速度太快,导致接收端的结束缓冲区很快的填充满了。此时如果发送端仍旧发送数据,那么接下来发送的数据都会丢包,继而导致丢包的一系列连锁反应,超时重传呀什么的。而TCP根据接收端对数据的处理能力,决定发送端的发送速度,这个机制就是流量控制。

在TCP协议的报头信息当中,有一个16位字段的窗口大小。在介绍这个窗口大小时我们知道,窗口大小的内容实际上是接收端接收数据缓冲区的剩余大小。这个数字越大,证明接收端接收缓冲区的剩余空间越大,网络的吞吐量越大。接收端会在确认应答发送ACK报文时,将自己的即时窗口大小填入,并跟随ACK报文一起发送过去。而发送方根据ACK报文里的窗口大小的值的改变进而改变自己的发送速度。如果接收到窗口大小的值为0,那么发送方将停止发送数据。并定期的向接收端发送窗口探测数据段,让接收端把窗口大小告诉发送端。

  1. 拥塞控制

    TCP传输的过程中,发送端开始发送数据的时候,如果刚开始就发送大量的数据,那么就可能造成一些问题。网络可能在开始的时候就很拥堵,如果给网络中在扔出大量数据,那么这个拥堵就会加剧。拥堵的加剧就会产生大量的丢包,就对大量的超时重传,严重影响传输。

    所以TCP引入了慢启动的机制,在开始发送数据时,先发送少量的数据探路。探清当前的网络状态如何,再决定多大的速度进行传输。这时候就引入一个叫做拥塞窗口的概念。发送刚开始定义拥塞窗口为 1,每次收到ACK应答,拥塞窗口加 1。在发送数据之前,首先将拥塞窗口与接收端反馈的窗口大小比对,取较小的值作为实际发送的窗口。

    拥塞窗口的增长是指数级别的。慢启动的机制只是说明在开始的时候发送的少,发送的慢,但是增长的速度是非常快的。为了控制拥塞窗口的增长,不能使拥塞窗口单纯的加倍,设置一个拥塞窗口的阈值,当拥塞窗口大小超过阈值时,不能再按照指数来增长,而是线性的增长。在慢启动开始的时候,慢启动的阈值等于窗口的最大值,一旦造成网络拥塞,发生超时重传时,慢启动的阈值会为原来的一半(这里的原来指的是发生网络拥塞时拥塞窗口的大小),同时拥塞窗口重置为 1。

拥塞控制是TCP在传输时尽可能快的将数据传输,并且避免拥塞造成的一系列问题。是可靠性的保证,同时也是维护了传输的高效性。

  1. 丢弃重复数据

    通过前面的知识我们知道,在确认应答时,由于确认应答消息的丢失,那么接收方可能会收到发送方的重复数据,如下图所示:

而此时对于业务方来说,只需要一个数据就可以了,所以 TCP 还有一个机制,丢弃重复数据的机制,这样就能保证业务方接收到的数据是正确的了。TCP 会给每一个发送的包上加上一个编号,如果接收到了编号相同的数据包,那么就说明接收端得到了重复的包,丢弃即可。

————内容源于网络

以上是关于计算机网络复习总结2的主要内容,如果未能解决你的问题,请参考以下文章

计算机网络复习2---UDP数据报首部格式的问题

计算机网络针对性复习

计算机网络针对性复习

计算机网络针对性复习

计算机网络复习6---TCPUDPIP的最长长度

计算机网络复习6---TCPUDPIP的最长长度