（个人经历）实习生春招面试中的TCP/IP常见（安全）问题及其相应解答

阿里云后端C/C++实习生面试，本人本科大三网络安全专业，总结了一下面试中关于TCP/IP的相关问题，整理如下，期间参考的其他博客我会列出源地址。我尽量做一些自己的理解后的整理的答案，以面试中一问一答的形式呈现。可能因为我菜，有些问题没有问得很深入。可能有不对的地方，欢迎在评论区留言指出。
让我们开始吧~

流量控制+拥塞控制

参考链接：https://zhuanlan.zhihu.com/p/37379780

流量控制：

流量控制的原因？

由于本地数据包传输过快，可能导致接收方来不及接受发送方发出的大量数据包。为了避免这种现象发生，需要发送方控制发送数据包的速度，因此需要“流量控制”。

如何才能做到流量控制？协议如何实现？

主要的方式就是接收方返回的 ACK 中会包含自己的接收窗口的大小，并且利用大小来控制发送方的数据发送。当发送方注意到自己发送的数据包序号超过接收方能接受的窗口大小时，停止发送数据包。

拥塞控制

拥塞控制的原因？简单描述一下原理？

需要进行拥塞控制的原因往往是因为网络的问题，可能某些时刻如双十一期间，某些站点或者服务器的访问量超过了网络能承载的范围，在队列已满的时候，为了保证公平，会采用随机丢包的方式来减轻网络压力。当TCP/IP协议检测到网络开始随机丢包时，就通过拥塞控制来调整发包速率，减轻网络负担。

当发送方发现丢包了会怎么做？

现在一般采用TCP Reno版本，也就是发包速率减半，然后再线性增加直到再出现丢包，如此循环。

三次握手

https://www.cnblogs.com/quehualin/p/10409607.html

三次握手中，可能会遇到什么样的情况？如何应对？

链接建立前：
1.SYN丢失、或者第一个回应的ACK没有被收到：发送方不断尝试发送syn，直到收到ack；忍受时间阈值：75s
2.接收方收到SYN，发出ACK包，此ACK包丢失：发送方同1中不断尝试，接收方超过时间没有收到第三步握手的SEQ+ACK包会不断重复发出ACK。忍受时间阈值与1相同。
3.发送方收到第二步的ACK包，状态变为ESTABLISHED，发出第三步的SEQ+ACK，若此包丢失：那么发送端该TCP连接的状态为SYN_RECV，并且依次等待3秒、6秒、12秒后重新发送SYN+ACK包，以便重新发送ACK包。发送端重发SYN+ACK包的次数，可以通过设/proc/sys/net/ipv4/tcp_synack_retries修改，默认值为5。如果重发指定次数后，仍然未收到ACK应答，那么一段时间后，发送方关闭连接。

https://www.nowcoder.com/tutorial/93/e1b14ab2b40a4ef98d9e55830eb48d66

TCP/IP是如何保证协议稳定的？

（1）序列号、确认应答、超时重传
（2）窗口控制与高速重发控制/快速重传（重复确认应答）
（3）拥塞控制

在上述（2）中重复确认应答的过程中，采用什么样的方式确认？

接收方发送ACK指示下一个期待接收到的包。

如果上述ACK包丢了该怎么办？

以倍增的时间如3s,6s,12s……发送方不断重复发送上一个ACK中指示的包，直到收到新的ACK包，若超过一定时间阈值仍然没有收到ACK确认，断开连接，以减小网络的资源浪费。（我忘了时间阈值是20min还是2h）

四次挥手

面试官没有细问我这个，就问我知不知道，我说知道，可能我前面答得比较好，他说那OK。那我也复制粘贴一下：

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

1.数据传输结束后，客户端的应用进程发出连接释放报文段，并停止发送数据，客户端进入FIN_WAIT_1状态，此时客户端依然可以接收服务器发送来的数据。

2.服务器接收到FIN后，发送一个ACK给客户端，确认序号为收到的序号+1，服务器进入CLOSE_WAIT状态。客户端收到后进入FIN_WAIT_2状态。

3.当服务器没有数据要发送时，服务器发送一个FIN报文，此时服务器进入LAST_ACK状态，等待客户端的确认

4.客户端收到服务器的FIN报文后，给服务器发送一个ACK报文，确认序列号为收到的序号+1。此时客户端进入TIME_WAIT状态，等待2MSL（MSL：报文段最大生存时间），然后关闭连接。

为什么挥手需要四次但是握手只用三次？

挥手时FIN和ACK分别发送。

接上一问， 为什么要分别发送，不能和建立链接时一样一起发送吗？

1、当客户端确认发送完数据且知道服务器已经接收完了，想要关闭发送数据口（当然确认信号还是可以发），就会发FIN给服务器。

2、服务器收到客户端发送的FIN，表示收到了，就会发送ACK回复。

3、但这时候服务器可能还在发送数据，没有想要关闭数据口的意思，所以服务器的FIN与ACK不是同时发送的，而是等到服务器数据发送完了，才会发送FIN给客户端。

4、客户端收到服务器发来的FIN，知道服务器的数据也发送完了，回复ACK， 客户端等待2MSL以后，没有收到服务器传来的任何消息，知道服务器已经收到自己的ACK了，客户端就关闭链接，服务器也关闭链接了。

http与https

为什么需要https？

http有很多缺点，现在很多事情需要更高更好的安全，而运算速度的提升使得额外开销可以被接受，https能够更加做到安全，所以会被采用。

https是怎么实现安全传输的？

通过SSL和TSL协议。HTTPS = HTTP + SSL/TLS。即不安全的 HTTP 协议加上 SSL/TLS 等于安全的 HTTPS。
网站首先花钱从权威 CA 机构那里购买一个数字证书，证书通常包含一个私钥和一个公钥证书文件。浏览器访问网站时将公钥证书文件发送给浏览器，浏览器验证收到的证书（权威机构担保真假，主流浏览器和操作系统都会内置权威 CA 机构的根证书）如果证书可信，就随机生成一个对称加密密钥 k，使用公钥加密 k，得到密钥 c。将密钥 c 发送到网站，网站根据私钥解密出密钥 k，至此密钥交换完成。这就是 HTTPS 加密传输的过程。

TCP头标一共几位？

20个字节160位。（面试的时候我说我记得是32比特的整数倍，大概128比特左右……）
具体定义如下代码所示：

/*TCP头定义，共20个字节*/
typedef struct _TCP_HEADER 
{
 short m_sSourPort;        　　　　　　// 源端口号16bit
 short m_sDestPort;       　　　　　　 // 目的端口号16bit
 unsigned int m_uiSequNum;       　　// 序列号32bit
 unsigned int m_uiAcknowledgeNum;  // 确认号32bit
 short m_sHeaderLenAndFlag;      　　// 前4位：TCP头长度；中6位：保留；后6位：标志位
 short m_sWindowSize;       　　　　　// 窗口大小16bit
 short m_sCheckSum;        　　　　　 // 检验和16bit
 short m_surgentPointer;      　　　　 // 紧急数据偏移量16bit
}__attribute__((packed))TCP_HEADER, *PTCP_HEADER;

图片来源看水印；
顺带一提，udp的头短得多，只有8字节。

以上就是我的总结了，希望看到这里的读者点个小赞，或者评论区给我提出意见，让我知道有人在看我的文章！这会是我更新的最大动力，谢谢！