舌战面试官 -计网篇（二）

上次我们讲了OSI七层协议，TCP与UDP的区别，还有TCP为什么可靠这几个面试必问题，很老套但要仔细的说好，还是要花点时间去复习的，还有不清楚的小伙伴请移步

舌战面试官-计网篇（一）

这次我们再接着讲讲传输层的TCP和UDP协议的常见面试题：

一.TCP三次握手，为什么要三次握手？？

tcp在建立连接时总共要传输三个数据包，抽象的叫它"三次握手";

首先我们要了解TCP的数据报文段结构是怎样的？

1. 序号：Seq ，用于标识计算机A到计算机B的数据包的序号
2. 确认号：Ack，指明下一个期待收到的字节序号，表明该序号之前的所有数据已经正确无误的收到。确认号只有当ACK标志为1时才有效。比如建立连接时，SYN报文的ACK标志位为0。Ack=Seq+1。
3. 标志位：总共有6个，分别为URG,ACK,PSH,RST,SYN,FIN，我们重点关注ACK,SYN和FIN,
   简要的说ACK是确认序号有效；SYN是建立一个连接；FIN是断开一个连接

1）URG：紧急指针标志，为1时表示紧急指针有效，为0则忽略紧急指针。

2）ACK：确认序号标志，为1时表示确认号有效，为0表示报文中不含确认信息，忽略确认号字段。

3）PSH：push标志，为1表示是带有push标志的数据，指示接收方在接收到该报文段以后，应尽快将这个报文段交给应用程序，而不是在缓冲区排队。

4）RST：重置连接标志，用于重置由于主机崩溃或其他原因而出现错误的连接。或者用于拒绝非法的报文段和拒绝连接请求。

5）SYN：同步序号，用于建立连接过程，在连接请求中，SYN=1和ACK=0表示该数据段没有使用捎带的确认域，而连接应答捎带一个确认，即SYN=1和ACK=1。

6）FIN：finish标志，用于释放连接，为1时表示发送方已经没有数据发送了，即关闭本方数据流

过程描述：
1.第一次握手：客户端发送一个SYN序列号 ，假设SYN为x ,表示要和服务器建立连接；

注意：此时客户端既不知道自己是否正确发送出数据，也不知道服务器能否接收，所以我们需要第二次握手

2 .第二次握手：服务器接收并响应一个 ACK = SYN+1=x+1,表示可以建立连接；因为TCP是全双工的，所以在此响应也要加上一个 SYN序列号，假设为K。

注意：这时客户端受到确认后知道服务器具备收和发的功能，但是服务器只知道客户端可以发数据，不知道能不能正确收到数据；而且服务端也不知道自己是否正确发出数据。所以我们需要第三次握手的一个原因

3.第三次握手：客户端受到新的SYN = K和ACK确认之后，也回应一个ACK=SYN+1=K+1;这样连接就建立起来了；

注意：此时双方都知道对方具备接收和发送数据的能力，这样一个可靠的连接就建立了

第三次握手还有一个重要的原因就是：

1.防止失效的客户端请求在此传给服务器，就是说客户端A发出的连接请求没有收到服务器B的确认（请求并没丢失），过来一段时间后客户端A又发送请求，和B建立好连接；

然后失效的请求到了服务器B,B以为是A发送的新的连接，并向A发送确认，A知道自己的无效请求就丢弃掉，而B还在傻傻的等A发数据，浪费自己宝贵的青春（这就是没有三次握手的下场）

二.那为什么挥手要四次呢，挥手的过程是什么，为什么要求关闭方在关闭前等待2MSL(TIME_WAIT)*？

由于TCP连接是全双工的，因此每个方向都必须单独进行关闭。这原则是当一方完成它的数据发送任务后就能发送一个FIN来终止这个方向的连接。收到一个 FIN只意味着这一方向上没有数据流动，一个TCP连接在收到一个FIN后仍能发送数据。首先进行关闭的一方将执行主动关闭，而另一方执行被动关闭

1） TCP客户端发送一个FIN，用来关闭客户到服务器的数据传送。

2） 服务器收到这个FIN，它发回一个ACK，确认序号为收到的序号加1。

3） 服务器关闭客户端的连接，发送一个FIN给客户端。

4） 客户端发回ACK报文确认,并将确认序号设置为收到序号加1。

那为什么要进行四次挥手呢？
在断开连接时，
A发送FIN,说：B啊，我不和你玩了可以吗？
此时A进入FIN_WAIT_1状态

B回复ACK说： 你不想玩了是吧，我懂了！
B进入CLOSE_WAIT状态，A收到后进入FIN_WAIT_2状态

这时候，B可以直接把FIN和ACK一起发给A，直接跑路吗？不可以！因为你A玩够了，我B还有话和你说呢，B要说完了，大家才能够说拜拜，此时B还有事，还是可以发送数据的，所以需要四次挥手，而不是三次

这时候A可以选择不再接受数据，也可以选择接受最后一段数据，等B主动关闭;

B说完最后的话后，发送一个FIN:我没话说了，拜拜了您嘞；

A回复ACK ：嗯，拜拜。

为什么要求关闭方在关闭前等待2MSL(TIME_WAIT)

A收到B发送的FIN说：我没话说了，拜拜了您嘞；然后发送完一个ACK后，应该就可以直接关闭连接跑路了对不对，

但是如果这个ACK确认B没有收到，超时了B就会重传FIN，但是A已经关闭连接跑路了，那B收不到确认岂不是永远都关闭不了？

所以TCP要求A在发送完最后一个ACK后，等待一段时间，这个时间要比B超时重传的时间长，要保证能让A收到B重传的FIN，再次发送ACK并能到达B。

三.如果已经建立了TCP连接,客户端突然出现故障怎么办？

显然服务器不能一直等下去，这样白白浪费了资源。TCP为此维护了一个保活计时器。

服务器每次收到请求都会复位这个计时器为0；默认情况下，两个小时服务器没有收到客户端的请求，就会每隔75s发送一个报文段，探测客户端能不能回应；如果连续10个探测报文段都没有收到回应，那服务器就会断开连接；

四.如果想使用UDP保证保证可靠性，我们该怎么做？

其实最简单的方法就是模仿TCP操作；但是UDP在传输层已经是不可靠了，所以我们就得在UDP对应的应用层协议做文章。
我们可以让它像TCP那样通过窗口机制实现流量控制，通过应答确认来检测包的差错，丢失，重序问题，并且设定超时重传计时器，实现确认超时就重传数据，

五. TCP/UDP对应的应用层协议有哪些？

tcp对应的应用层协议：

1. HTTP：超文本传输协议，使用80端口
2. FTP：文件传输协议，使用21端口，FTP提供交互式的访问；
3. SMTP:邮件传输协议，用于发送邮件，使用25端口
4. POP3：与SMTP对应，用于接收邮件，使用110端口
5. Telnet:远程登录协议，使用23端口、、

udp对应的应用层协议

1. DNS：实现域名解析服务，使用53端口，主要是把域名解析成ip地址。
2. SNMP：简单的网络管理协议，使用161端口；特长是管理数量众多的网络设备，比如一个局域网中的路由器。
3. TFTP:简单文件传送协议，基于UDP数据报，所以需要自己有差错修改机制；TFTP只支持文件传输，不支持交互；