面试题——TCP网络编程总结

1、TCP网络编程中三次握手、四次挥手的状态有几种

   在三次握手中客户端是主动打开，服务器端是被动打开，客户端的状态有6种（TIME_WAIT 2MSL之后变成CLOSED状态），服务器端状态5种

（1）三次握手：刚开始客户端和服务器端都属于关闭状态即closed，接着客户端主动打开，给服务器端发送请求报文后客户端变成STN-SENT（同步已发送）状态，服务器被动打开，接收到请求报文并给客户端回复确认报文之后服务器端变成SYN-RCVD（同步收到）状态，客户端收到确认报文并且给服务器端再发送确认报文后，客户端变成ESTAB-LISHED（已建立连接）状态，服务器端接收到客户端发送的第二次报文之后变成了ESTAB-LISHED（已建立连接）状态，三次握手完成，连接也就建立好了，然后开始进行数据传送。

（2）四次挥手，四次挥手时客户端和服务器端的起始状态就是刚刚三次握手结束时的状态，然后客户端进行主动关闭给服务器端发送结束报文段后，客户端变成FIN-WAIT-1(终止等待1)状态，服务器端收到客户端的结束报文段并且给客户端回复一个确认结束报文段之后服务器端变成CLOSE-WAIT状态（服务器端被动关闭）。客户端收到这个确认结束报文段之后变成FIN_WAIT2状态，然后处于LAST_ACK状态的服务器端给客户端发送结束报文段，客户端收到该结束报文段并且给服务器端再发送确认结束报文段之后客户端就变成了TIME-WAIT状态，在服务器端收到该报文段之后服务器端进入CLOSED关闭状态，等待2MSL时间之后，客户端也变成了CLOSED状态。

2、TCP的三次握手为什么不是两次(为什么是三次握手)？

     这是为了防止已失效的链接请求报文段突然又传到服务器端，因而产生错误。

所谓“已失效的连接请求报文段”是这样产生的，考虑一种正常的情况，客户端发出请求，但因为连接的请求报文段丢失而未收到确认，于是客户端再重传一次连接请求，后来收到了确认，建立了连接，数据传输完毕之后，释放连接。客户端一共发送了两个连接请求报文段，其中第一个丢失，第二个到达了服务器端，没有已失效的连接请求报文

现假定出现一种异常的情况，即客户端发出第一个请求报文并没有丢失，而是在某些网络节点长时间滞留了，以致延误到连接释放以后的某个时间才到达服务器端，本来这是一个早已失效的报文段，但服务器收到此失效的连接请求报文段后，就误认为是客户端已发出一次新的连接请求，于是服务器端向客户端发出确认报文段，同意连接。如果不采用第三次的确认回复报文，那么只要在服务器发出确认，新的连接就建立了，由于现在客户端没有发出建立连接的请求，因此不会理会服务器端的确认，也不会向服务器发送数据，但服务器端以为新的连接已经建立了，并一直等待客户端发送数据，这样的话，服务器的许多资源就这样白白浪费了。

3、四次握手可以吗？可以

 

4、分析四次挥手的场景？

关闭连接的过程为四次挥手，由于TCP是全双工的通讯，所以每个方向都必须单独进行关闭，当一方完成它的数据发送任务之和就能发送一个FIN结束报文来终止这个方向上的连接。收到一个FIN结束报文意味着这一方向上没有数据流动，一个TCP连接在收到一个FIN后仍能继续发送数据。首先进行关闭的一方执行主动关闭，而另一方执行被动关闭。

5、TIME_WAIT状态的意义？

（1）保证迟来的报文能被识别并丢弃。有可能对端发送的FIN报文段比之前发送的报文段先到达本端，那么如果本端在收到对端的FIN报文后就直接进入CLOSED状态，这些迟来的数据就不能被识别了。

（2）保证可靠的终止TCP连接。保证对端能收到最后的一个ACK，如果ACK丢失，在TIME_WAIT状态本端还可以接受到对端重传的FIN报文段，并重新发送ACK。所以TIME_WAIT的存在时间为2MSL。

6、为什么客户端在TIME-WAIT状态必须等待2MSL？

因为TCP报文段的最大生存时间是MSL，所以坚持2MSL时间的TIME_WAIT状态能够确保网络上两个传输方向上尚未被接收到的、迟到的TCP报文段都已消失（被中转路由丢弃）。因此，一个连接的新的化身可以在2MSL时间之后安全的建立连接，而绝不会收到原来连接的应用程序数据。

如果TIME_WAIT不等待2MSL时长，则会出现下面的问题：（1）旧的TCP连接已经不存在了，系统此时只能返回RST包。（2）新的TCP连接被建立起来了，延迟包可能干扰新的连接，

7、为什么客户端主动执行close关闭连接之后，立即重启客户端程序还能连接成功？

对于客户端程序来说，我们通常是不用担心的上述的重启问题，因为客户端一般使用自动分配的临时端口建立连接，而由于随机性，临时端口一般和程序上一次使用的端口号（还处于time_wait）状态的哪个连接使用的端口号不同，所以客户端一般可以立即重启

8、为什么服务器主动执行close关闭连接之后，再立即重启服务器程序却不成功？

对于服务器主动关闭连接后属于异常终止，因为它总是使用同一个知名服务器端口号，所以连接的TIME_WAIT状态导致它不能立即 重启，不过我们可以通过socket选项SOREUSEADDR来强制进程liji使用处于TIME_WAIT状态的连接占用的端口号

9、CLOSE_WAIT和TIME_WAIT有什么去别？

（1）CLOSE_TIME是被动关闭的一端在接收到对端关闭请求（FIN报文段）并且将ACK发送出去后所处的状态，这种状态表示：收到了对端关闭请求，但是本段还没有完成工作，还未关闭

（2）TIME_WAIT状态是主动关闭的一端在本端已经关闭的前提下，收到对端的关闭请求（FIN报文段）并且将ACK发送出去后所处的状态，这种状态表示：双方都已完成工作，只是为了确保迟来的数据报能被识别并丢弃，可靠的终止TCP连接

10、TCP网络编程中，connect系统调用失败的原因？

（1）如果connect连接的目标端口不存在，（未被任何进程监听），或者该端口仍处于TIME_WAIT状态的连接所占用，则服务器将给客户端发送一个复位报文段，connect调用失败

（2）如果目标端口存在，但connect在超时时间内未收到服务器确认报文段，则connect调用失败

11、TCP可靠传输的原因

（1）TCP协议采用发送应答机制，即发送端发送的每个数据段都必须得到接收方的应答，才能认为这个TCP报文段传输成功

（2）TCP采用超时重传机制，发送端在发送出一个TCP消息之后，启动定时器，如果在定是时间内未收到应答，它将重新发送

（3）由于TCP数据报最终是以IP数据报发送的，而IP数据报到达接收端可能乱序、重复，所以TCP协议还会将接收到的TCP报文段重排、整理、再交付给应用层。

12、半关闭状态

    TCP连接是全双工的，所以允许两端的数据传输被独立关闭，也就是说通信的一端可以发送结束报文给对方，告诉它本端已经完成数据的发送，但允许继续接收来及对方的数据，直到对方发送报文段以关闭连接

13、TCP三次握手哪一阶段容易受到攻击，为什么？

SYN溢出攻击，即出现在第二个阶段，如果客户机伪造出大量第一次的SYN报文，服务器端就会依次消耗很多资源来保存客户端的信息，并进行确认，实际确认是会失败，但失败是需要一定时间，因为服务端会连续多次进行第二次握手确认后才失败。那么短的时间有大量SYN同步报文涌向服务端，服务器资源可能被消耗尽，就可能导致正常的客户端得不到响应而失败

14、TCP网络编程中Listen的第二个参数有什么意义？它太大或者太小有什么影响？

    Listen函数原型    int listen(int listenfd, int size);

    Listenfd：指定监听的文件描述符

    size：指定内核维护的已完成三次握手的队列的大小，实际维护的队列的大小为size+1。如果这个值太小，那么服务器能维护的已完成三次握手的但是没有accept的连接数就会很小，导致完成三次握手，等待服务器处理的客户端数量很少。如果这个值很大，那么就导致服务器这边的内核资源浪费。但是如果开启syncookies，则忽略第二个参数。

   size在linux中仅表示已完成三次握手的队列长度，在内核2.6中是5~128，在unix网络编程中这个size表示两个队列之和

15、数据流服务和数据报服务的特点和区别？

字节流服务发送端应用层send的次数与传输层封装的TCP报文段个数无关，接收端传输层接收到的TCP报文段的个数也与应用层recv的次数无关。如果一次recv没有将数据读完，则剩余的数据还会保存在TCP的接收缓冲区中，而数据报服务一次sendto对应一个UDP数据报，一个UDP数据报也只会有一次recvfrom获取，如果一次recvfrom没有将一个UDP数据报的数据获取完，则剩余的数据被丢弃。

16、建立连接过程主要解决一下问题？

（1）要使每一方能过确知对方的存在

（2）要允许双方协商一些参数（如最大窗口值、是否使用窗口扩大选项和时间戳选项以及服务质量等）

（3）能够对运输实体资源（如缓存大小、连接表中的项目等）进行分配

（4）防止已失效的连接突然又传到服务器端，从而产生错误。

17、TCP/IP的四层协议，为什么要有传输层和网络层？

TCP/IP模型是互联网最基本也是最核心的协议模型。

（1）应用层：负责向用户提供常用的应用服务。主要协议：http、ftp、dns、telnet等。

（2）传输层：负责向上层提供端到端的服务，控制数据传输的方式，保证“报文”无差错、有序、不丢失、不重复的传输。它向上层屏蔽了数据通讯的细节，是计算机通讯体结构最关键的一层。主要协议：TCP、UDP

（3）网络层：负责网络中主机间的“分组”传输，对数据的传输路线进行控制，保证数据能够到达本端。主要协议：IP协议、ICMP协议、ARP&RARP协议

（4）数据链路层：数据链路层是物理传输通道，可使用多种传输介质传输。

  如果没有传输层和网络层会出现以下的情况：a、如果没有网络层，数据能不能再数据链路上传输呢？当然是不能的，因为数据链路层对传输的数据大小是有要求的，例如：以太网的MTU（网络最大传输单元）为1500byte。而且，在如此复杂的网络环境中，没有网络层，也就无法选择数据传输的线路，无法保证数据能到达对端。b、如果没有传输层，那么数据传输的安全性、可靠性就没办法保证。

18、若客户端和服务器端已经建立连接，但后来客户端主机突然出现故障，此时服务器端怎么知道客户端是否出故障呢？

    保活计时器（心跳包问题），很显然当客户端主机发生故障之后服务器端就不能再收到客户端发来的数据，如果服务器端就这么白白等下去是很浪费资源的，这时就是用保活计时器，服务器每收到一次客户端的数据，就重新设置保活计时器，时间的设置通常是两小时，若两小时没有收到客户的数据，服务器就发送一个探测报文段，以后则每隔一=75秒发送一次。若一连发送19个探测报文段后仍无客户的响应，服务器就认为客户端出现了故障，接着就关闭了连接

19、怎么提高UDP协议的可靠性？

TCP实现了可靠的数据传输，UDP是不可靠的，所以传输层未实现的可靠性要在应用层实现。TCP为了实现可靠的传输，是以浪费部分带宽，牺牲实时性为代价的。UDP效率高，代价小，可以在应用层实现类似的应答机制，快速重传的方法来提高相应的可靠性。

20、用户数据报协议UDP

（1）UDP是无连接的，即在发送数据之前不需要建立连接，减少了开销和发送数据之前的时延

（2）UDP使用尽最大努力交付，即不保证可靠交付。

（3）UDP是面向报文的。发送方的UDP对应用程序交下来的报文，加上首部就向下层的IP层交付。UDP对应用层交下来的报文，既不合并也不拆分，而是保留这些报文的边界。也就是说应用层交给UDP多长的报文，UDP就照样发送，即一次发送一个报文。在接收方的UDP，对IP层交上来的UDP用户数据报在去除首部后就原封不动的交付给上层的应用进程。即UDP一次交付一个完整的报文。因此应用程序必须选择合适大小的报文，若报文太长，UDP把它交给IP层后，IP层在传送时可能要进行分割，这会降低IP层的效率。反之，若报文太短，UDP把它交给IP层后，会使IP数据报的首部的相对长度太大，这也降低了IP层的效率

（4）UDP没有拥塞控制，所以网络出现的拥塞不会使源主机的发送速率降低，这对某些实时应用很重要（比如：IP电话、实时视频会议）要求源主机以恒定的速率发送数据，并且允许在网络发生拥塞时丢失一些数据，却不允许数据有太大的时延。UDP正好适合这种要求

（5）UDP的首部开销小，只有8字节，比TCP的20字节的首部短

21、不使用拥塞控制功能的UDP有可能会引起网络产生严重的拥塞问题。

   比如：某些实时应用需要使用没有拥塞控制的UDP，但当很多的源主机同时都向网络发送高速率的实时视频交流时，网络就有可能发生拥塞，结果大家都无法正常接收。

22、UDP、TCP的应用场景