python_面试题_TCP的三次握手与四次挥手问题

1.相关问题

问题1: 请详细描述三次握手和四次挥手的过程，并画出状态图

问题2: 四次挥手中TIME_WAIT状态存在的目的是什么?

问题3: TCP是经过什么机制保障可靠性的?

 

2.问题回答

问题1：

状态图以下

补充知识：TCP报文中共计6个标志位，每一个标志位占1个字节，即URG、ACK、PSH、RST、SYN、FIN等

• URG：紧急指针（urgent pointer）有效。
• ACK：确认序号有效。
• PSH：接收方应该尽快将这个报文交给应用层。
• RST：重置链接。
• SYN：发起一个新链接。
• FIN：释放一个链接。

三次握手详情

1. 第一次握手：Client将标志位SYN置为1，随机产生一个值seq=a，并将该数据包发送给Server，Client进入SYN_SENT状态，等待Server确认。
2. 第二次握手：Server收到数据包后由标志位SYN=1知道Client请求创建链接，Server将标志位SYN和ACK都置为1，ack=a+1，随机产生一个值seq=b，并将该数据包发送给Client以确认链接请求，Server进入SYN_RCVD状态。
3. 第三次握手：Client收到确认后，检查ack是否为a+1，ACK是否为1，若是正确则将标志位ACK置为1，ack=b+1，并将该数据包发送给Server，Server检查ack是否为b+1，ACK是否为1，若是正确则链接创建成功，Client和Server进入ESTABLISHED状态，完成三次握手，随后Client与Server之间能够开始传输数据了。

四次挥手详情（被动关闭）

1. 第一次挥手：Client发送一个FIN，随机产生一个值seq=a，用来关闭Client到Server的数据传送，Client进入FIN_WAIT_1状态。
2. 第二次挥手：Server收到FIN后，发送一个ACK给Client，ack=a+1，Server进入CLOSE_WAIT状态。
3. 第三次挥手：Server发送一个FIN，随机产生一个值seq=b,用来关闭Server到Client的数据传送，同时发送ACK标志位，ack=a+1,Server进入LAST_ACK状态。
4. 第四次挥手：Client收到FIN后，Client进入TIME_WAIT状态，接着发送一个ACK给Server，ack=b+1，Server进入CLOSED状态，完成四次挥手。

补充1：

　　SYN攻击：在三次握手过程当中，Server发送SYN-ACK以后，收到Client的ACK以前的TCP链接称为半链接（half-open connect），此时Server处于SYN_RCVD状态，当收到ACK后，Server转入ESTABLISHED状态。SYN攻击就是Client在短期内伪造大量不存在的IP地址，并向Server不断地发送SYN包，Server回复确认包，并等待Client的确认，因为源地址是不存在的，所以，Server须要不断重发直至超时，这些伪造的SYN包将产时间占用未链接队列，致使正常的SYN请求由于队列满而被丢弃，从而引发网络堵塞甚至系统瘫痪。SYN攻击时一种典型的DDOS攻击，检测SYN攻击的方式很是简单，即当Server上有大量半链接状态且源IP地址是随机的，则能够判定遭到SYN攻击了，使用以下命令可让之现行：
#netstat -nap | grep SYN_RECV

补充2：

　　四次挥手的同时关闭情况：实际中还会出现同时发起主动关闭的状况，具体流程以下图

 

问题2：

在四次挥手中，第三次挥手结束后，Client端进入TIME_WAIT状态，客户端不会立刻进入closed状态，理由以下

1. 等待2MSL时间段，确保Client端发送的FIN报文，Server端能够接收，若是Server端没有收到第四次挥手，则会对Client端重发第三次挥手，确保Client能够正确关闭，若是没有进入TIME_WAIT状态，则Client端就没法接收Server端的发来的报文。简略：确保客户端正确关闭。
2. 一个链接结束，网络内路由或者是网络包还会继续保留一段时间，在tcp链接结束后，在旧TCP链接对应的网络包消失以前，才容许创建新的TCP链接。简略：在新的TCP创建以前，确保旧的TCP连接对应的网络包正确的结束。

 

问题3：

TCP传输的可靠性主要靠如下手段来保证传输

1. ACK确认机制：简单的说就是发送随机生成一个数字，接收端在确认收到数据，提取随机数并加1，返回发送端，告知确认收到数据包，同时也保证数据接收的惟一性
2. 超时重传：发送方在必定时间内未收到对方的回传的ack确认码，则将数据从新发送，保证数据传输的一致性
3. 滑动窗口：看补充
4. 流量控制：看补充

建议：滑动窗口与流量控制视状况是否说明

补充：滑动窗口与流量控制

1）.滑动窗口：

“窗口”对应的是一段能够被发送者发送的字节序列，其连续的范围称之为“窗口”；

“滑动”则是指这段“容许发送的范围”是能够随着发送的过程而变化的，方式就是按顺序“滑动”。

1. TCP协议的两端分别为发送者A和接收者B，因为是全双工协议，所以A和B应该分别维护着一个独立的发送缓冲区和接收缓冲区，因为对等性（A发B收和B发A收），咱们以A发送B接收的状况做为例子；
2. 发送窗口是发送缓存中的一部分，是能够被TCP协议发送的那部分，其实应用层须要发送的全部数据都被放进了发送者的发送缓冲区；
3. 发送窗口中相关的有四个概念：已发送并收到确认的数据（再也不发送窗口和发送缓冲区以内）、已发送但未收到确认的数据（位于发送窗口之中）、容许发送但还没有发送的数据以及发送窗口外发送缓冲区内暂时不容许发送的数据；
4. 每次成功发送数据以后，发送窗口就会在发送缓冲区中按顺序移动，将新的数据包含到窗口中准备发送；

案例以下：

     TCP创建链接的初始，B会告诉A本身的接收窗口大小，好比为‘20’：
     字节31-50为发送窗口

     A发送11个字节后，发送窗口位置不变，B接收到了乱序的数据分组：

     只有当A成功发送了数据，即发送的数据获得了B的确认以后，才会移动滑动窗口离开已发送的数据；同时B则确认连续的数据分组，对于乱序的分组则先接收下来，避免网络重复传递：

2）.流量控制

     流量控制方面主要有两个要点须要掌握。一是TCP利用滑动窗口实现流量控制的机制；二是如何考虑流量控制中的传输效率。
1. 流量控制
     所谓流量控制，主要是接收方传递信息给发送方，使其不要发送数据太快，是一种端到端的控制。主要的方式就是返回的ACK中会包含本身的接收窗口的大小，而且利用大小来控制发送方的数据发送，案例如图：

     这里面涉及到一种状况，若是B已经告诉A本身的缓冲区已满，因而A中止发送数据；等待一段时间后，B的缓冲区出现了富余，因而给A发送报文告诉A个人rwnd大小为400，可是这个报文不幸丢失了，因而就出现A等待B的通知||B等待A发送数据的死锁状态。为了处理这种问题，TCP引入了持续计时器（Persistence timer），当A收到对方的零窗口通知时，就启用该计时器，时间到则发送一个1字节的探测报文，对方会在此时回应自身的接收窗口大小，若是结果仍未0，则重设持续计时器，继续等待。
2. 传递效率
     一个显而易见的问题是：单个发送字节单个确认，和窗口有一个空余即通知发送方发送一个字节，无疑增长了网络中的许多没必要要的报文（请想一想为了一个字节数据而添加的40字节头部吧！），因此咱们的原则是尽量一次多发送几个字节，或者窗口空余较多的时候通知发送方一次发送多个字节。对于前者咱们普遍使用Nagle算法，即：

• 若发送应用进程要把发送的数据逐个字节地送到TCP的发送缓存，则发送方就把第一个数据字节先发送出去，把后面的字节先缓存起来；
• 当发送方收到第一个字节的确认后（也获得了网络状况和对方的接收窗口大小），再把缓冲区的剩余字节组成合适大小的报文发送出去；
• 当到达的数据已达到发送窗口大小的一半或以达到报文段的最大长度时，就当即发送一个报文段；

     对于后者咱们每每的作法是让接收方等待一段时间，或者接收方得到足够的空间容纳一个报文段或者等到接受缓存有一半空闲的时候，再通知发送方发送数据。

ok