计算机网络--TCP协议面试知识点总结

前言

昨天（2017.8.12）晚上9点多的时候突然接到百度的面试电话，上来就让自我介绍，介绍完之后就开始问我知不知道滑动窗口协议，知不知道三次握手和四次挥手。于是今天又花点时间把TCP协议相关的做一下总结。

TCP特点

①TCP是面向连接的传输层协议。应用程序在使用TCP协议之前必须先建立TCP连接。在传送数据结束后，必须释放已经建立的TCP连接。

②每一条TCP连接只能有两个端点（endpoint），每一条TCP连接只能是点对点的。

③TCP提供可靠交付的服务。通过TCP连接传送的数据，无差错、不丢失、不重复、并且按序到达。

④TCP提供全双工通信。TCP连接的两端都设有发送缓存和接收缓存，用来临时存放双向通信的数据。在发送时，应用程序在把数据传送给TCP的缓存后，就可以处理其它事情，而TCP在适合的时候把数据发送出去。在接收时，TCP把收到的数据放入到缓存，上层的应用进程在适合的时候读取缓存中的数据。

⑤面向字节流。TCP中的流（Stream）指的是流入到进程或者从进程流出的字节序列。面向字节流的含义是：虽然应用程序和TCP的交换是一次一个数据块，但TCP把应用程序交下来的数据看成仅仅是一连串的无结构的字节流。

TCP发送方和接收方传输如下图：

TCP连接

每一条TCP连接唯一地被通信两端的两个端点（即两个套接字）所确定。即：

上面的 IP1和 IP2是两个端点的IP地址，port1 和 port2是两个主机应用的端口号，TCP连接的端点是套接字，同一个IP地址可以有不同的TCP连接，端口号不同连接不同，同一个端口号也可以有不同的TCP连接，因为TCP连接是由IP地址和端口号唯一确定的，两者缺一不可。

三次握手

由于TCP协议是面向连接的，在客户端与服务器端传输数据之前要建立连接，（三次握手协议是TCP协议特有的，UDP协议不会进行三次握手因为UDP协议不是面向连接的协议）。

如上图：三次握手分为三步：
①Client客户端主动打开连接发送一个SYN同步请求报文。等待服务器端回复。

②服务器端接到SYN请求报文后发送一个ACK同意连接并且SYN请求连接报文。

③客户端接到服务器的报文后发送一个ACK报文，连接完成，服务器和客户端可以开始通信。

更加详细的包括序列号等的图片如下：

为什么要三次握手

为了防止“已失效的连接请求报文段”突然又传送到了B。假设A向B发送了连接请求，但这个连接请求报文没有及时到达B，则A因为没有收到B的确认而重新发送一个连接请求报文，B确认后连接建立，然后进行一系列数据交换后关闭的连接。但此时之前A发送的连接请求报文突然到达了B，则B会对此发送确认，如果采用两次握手，那么此时AB又建立了连接，而A并没有数据向B发送，白白浪费B的资源。采用三次握手则不会出现这种情况，因为B向A发送确认时，A不会再给B发送确认，连接不会建立。

三次握手缺陷

1、SYN Flood 攻击

SYN- Flood攻击是当前网络上最为常见的DDoS攻击，也是最为经典的拒绝服务攻击，它就是利用了TCP协议实现上的一个缺陷，通过向网络服务所在端口发送大量 的伪造源地址的攻击报文，就可能造成目标服务器中的半开连接队列被占满，从而阻止其他合法用户进行访问。这种攻击早在1996年就被发现，但至今仍然显示 出强大的生命力。很多操作系统，甚至防火墙、路由器都无法有效地防御这种攻击，而且由于它可以方便地伪造源地址，追查起来非常困难。它的数据包特征通常 是，源发送了大量的SYN包，并且缺少三次握手的最后一步握手ACK回复。

**原理：**攻击者首先伪造地址对 服务器发起SYN请求，服务器回应(SYN+ACK)包，而真实的IP会认为，我没有发送请求，不作回应。服务 器没有收到回应，这样的话，服务器不知 道(SYN+ACK)是否发送成功，默认情况下会重试5次（tcp_syn_retries）。这样的话，对于服务器的内存，带宽都有很大的消耗。攻击者 如果处于公网，可以伪造IP的话，对于服务器就很难根据IP来判断攻击者，给防护带来很大的困难。

2、SYN Flood 防护措施

主要通过以下3种方式

1． 无效连接监视释放

这种方法不停的监视系统中半开连接和不活动连接，当达到一定阈值时拆除这些连接，释放系统资源。这种绝对公平的方法往往也会将正常的连接的请求也会被释放掉，”伤敌一千，自损八百“

2． 延缓TCB分配方法

SYN Flood关键是利用了，SYN数据报文一到，系统立即分配TCB资源，从而占用了系统资源，因此有俩种技术来解决这一问题

Syn Cache技术

这种技术在收到SYN时不急着去分配TCB，而是先回应一个ACK报文，并在一个专用的HASH表中（Cache）中保存这种半开连接，直到收到正确的ACK报文再去分配TCB。

Syn Cookie技术

Syn Cookie技术则完全不使用任何存储资源，它使用一种特殊的算法生成Sequence Number，这种算法考虑到了对方的IP、端口、己方IP、端口的固定信息，以及对方无法知道而己方比较固定的一些信息，如MSS、时间等，在收到对方 的ACK报文后，重新计算一遍，看其是否与对方回应报文中的（Sequence Number-1）相同，从而决定是否分配TCB资源。

3． 使用SYN Proxy防火墙

原理：对试图穿越的SYN请求进行验证之后才放行。

四次挥手

当客户端和服务器数据传送完成时要断开TCP连接，断开TCP连接要进行四次挥手处理如下图：

①由上图可知刚开始客户端和服务器处于连接状态时客户端和服务器端可以双向传递数据，

②然后客户端向服务器发送FIN报文请求中断连接，发送完报文后客户端处于FIN_WAIT_1状态等待服务器响应，当服务器端接收到FIN报文并发送ACK同意关闭后，客户端向服务器端发送数据的通路关闭，此时客户端不能再向服务器端发送数据并且处于FIN_WAIT_2状态等待服务器端断开连接。

③但是由于TCP是全双工工作的，服务器端依然可以向客户端发送数据。服务器端向客户端发送FIN关闭连接请求，客户端回复ACK报文后开始计时进入TIME_WAIT状态。

④客户端等待2MSL（Maximum segment lifetime），MSL是报文最大生存时间，它是任何报文段被丢弃前在网络内的最长时间。在2MSL时间内Socket中使用的本地端口不能被使用。

注意：，要等待2MSL的原因是怕客户端向服务器发送的ACK报文丢失，如果2MSL时间后服务器端没有接到ACK报文（TCP中有超时重传机制），还会再次向客户端发送一个FIN报文，直到最后服务器端接到ACK正常关闭端口。

TCP可靠传输

TCP发送的报文段是交给IP层传送的。但是IP层只能提供尽最大努力服务，也就是说，TCP 下面的网络所提供的不是可靠传输。因此TCP必须采用恰当的措施才能使得两个传输层之间的通信变得可靠。TCP保证可靠的方式如下：

1.数据包校验：TCP会对整个报文段进行检验

2.滑动窗口机制：以字节为单位进行

3.超时重传机制：发送方在规定时间内没有收到确认就要重新发送报文

4.选择确认：当报文未按序到达时，若这些在接收窗口范围内，接收方就先收下然后将准确信息告诉发送方，让它不要重复发送。

5.流量控制和拥塞控制：通过发送窗口和接收窗口大小来实现

传输方式如下：

停止等待协议

“停止等待”就是每发送完一个分组就停止发送，等待对方的确认。在收到确认后再发送下一个分组。停止等待协议分为以下几种情况：

1、无差错情况

A 发送分组M1，发完就暂停发送，等待B 的确认。B 收到了M1 就向A 发送确认。A 在收到了对M1的确认后，就再发送下一个分组M2。同样，在收到B 对M2的确认后，再发送M3。

2、超时重传

B 接收M1时检测出了差错就丢弃M1，其他什么也不做，不通知A 收到有差错的分组户。也可能是M1 在传输过程中丢失了，这时B 当然什么都不知道。在这两种情况下， B都不会发送任何信息。可靠传输协议是只要超过了一段时间仍然没有收到确认，就认为刚才发送的分组丢失了，因而重传前面发送过的分组。这就叫做超时重传。要实现超时重传，就要在每发送完一个分组设置一个超时计时器。如果在超时计时器到期之前收到了对方的确认，就撤销己设置的超时计时器。

注意以下三点：

1、A在发送完一个分组后，必须暂时保留已发送分组的副本（为发生超时重传时使用）。只有在收到相应的确认后才能清除暂时保留的分组副本。

2、分组和确认分组都必须进行编号。这样才能明确是哪一个发送出去的分组收到了确认，而哪一个分组还没有收到确认。

3、超时计时器设置的重传时间应当比数据在分组传输的欧诺个级往返时间更长一些。

3、确认丢失

B所发送的对M1的确认丢失了。A在设定的超时重传时间内没有收到确认，因此A 在超时计时器到期后就要重传M1。现在应注意B的动作。假定B又收到了重传的分组M1。这时应采取两个行动：

（1）丢弃重复的M1，不向上层交付。

（2）重新向A发送确认。不能认为已经发送给确认就不再发送，因为A之所以重传M2就表示A没有收到对M2的确认。

4、确认超时

传输过程中没有出现差错，但B 对分组M1 的确认迟到了。A 会收到重复的确认。对重复的确认的处理很简单：收下后就丢弃。B 仍然会收到重复的M1 ，并且同样要丢弃重复的M1 ，并重传确认分组。

滑动窗口协议

停止等待协议每发送一帧就要停止等待知道接收到确认帧，这样每次等待的时候不能传送数据使得传输效率很低。下图表示发送方维持的发送窗口，它的意义是：位于发送窗口内的5 个分组都可连续发送出去，而不需要等待对方的确认。这样，信道利用率就提高了。连续ARQ 协议规定，发送方每收到一个确认，就把发送窗口向前滑动一个分组的位置。

接收方一般都是采用累积确认的方式。这就是说，接收方不必对收到的分组逐个发送确认，而是可以在收到几个分组后，对按序到达的最后一个分组发送确认，这样就表示：到这个分组为止的所有分组都己正确收到了。

累积确认的优点是容易实现，即使确认丢失也不必重传。但缺点是不能向发送方反映出接收方己经正确收到的所有分组的信息。

滑动窗口协议分为两种一种是后退N帧协议（Back To N）,一种是选择重传协议。

1、后退N帧协议

如下图，如果发送方发送了前9个分组，而中间的第2 个分组丢失了。这时接收方只能对前两个分组发出确认。发送方无法知道后面7个分组的下落，而只好把后面的7个分组都再重传一次。这就叫做Go-back-N （回退N ），表示需要再退回来重传己发送过的N 个分组。可见当通信线路质量不好时，连续ARQ 协议会带来负面的影响。

2、选择重传协议

返回N协议简化了接收方的处理过程.接收方只需跟踪一个变量,并且不需要对失序到达的分组缓存,而是简单地把失序到达的分组它们丢掉.但是如果底下的网络层协议丢失了很多分组,那么返回N协议的效率就会很低.每当一个分组损坏,发送方就需要重传所有待确认的分组,虽然其中有些分组实际上已经完好地 被接收了。

选择重传协议也是滑动窗口协议，并且是在后退N帧的基础上进行了改进，选择重传协议，选择重传协议只重传真正丢失的分组.

选择重传协议的接收窗口和发送窗口一样大(2^m-1) 比返回N协议的窗口(2^m)小了一倍

选择重传的接收窗口与发送窗口一样大.选择重传协议允许与接受窗口一样多的分组失序到达,并保存这些失序到达的分组,直到连续的一组分组被交付给应用层.因为发送窗口与接收窗口是相同的,所以发送出来的所有分组都可以失序到达,而且会被保留直到交付为止.但是必须强调一点,在一个可靠的协议中,接收方永远不会把分组失序地交给应用层.在他们被交付给应用层之前,先要等待那些更早发出来的分组到达.

理论上选择重传协议要为每个分组使用一个计时器.当某个计时器超时后,只有相应的分组被重传.换而言之,返回N协议将所有的分组当做一个整体对待,而选择重传协议则分别对待每一个分组.但是大多数SR的运输层仅使用了一个计时器. 注意只使用一个计时器而做到跟踪所有发出去的分组的情况的做法是:标记发出分组,当ACK=Sf 时,将窗口滑过所有连续的已确认的分组,如果还有未确认的分组,则则重发所有检测到的未被确认的分组并重启计时器,如果所有分组都被确认了则停止计时器.

参考文献

1.TCP/IP详解
2.http://www.tcpipguide.com/free/t_TCPConnectionEstablishmentProcessTheThreeWayHandsh-3.htm
3.图解TCP/IP