一、前言
距离上一篇博客也有两星期了，本来说要写一些关于Python的博客，后来想了一想既然暂时是要准备找工作，那么总要准备一下面试，万一考研初试过了线，当然也要准备相关的面试，两者好像并不是很冲突，所以寒假期间就以面试为主，为春招做准备，前期主要是把一些常见的面试题过一遍，后面可能还要刷一些算法题。这一篇就先记录一下与计算机网络有关的面试题和相关的知识点。
有很多看我博客的小伙伴会私信我一些问题，但是写代码这件事情真的是几天不写就手生，更何况我这一年多都没怎么写代码的人，所以很多问题我真的也是无能为力，这里表示抱歉。
这些面试题基本都是出自慕课网的一个课程：戳我一下，有能力的读者，可以自己购买看看。
二、常见面试题
1、说说TCP的三次握手
TCP三次握手的流程图如下：
答案：
在TCP/IP协议中，TCP协议提供可靠的连接服务，采用三次握手建立一个连接。
第一次握手：建立连接时，客户端发送SYN包（seq=x）到服务器，并进入SYN_SENT状态，等待服务器确认；
第二次握手：服务器收到SYN包， 必须确认客户的SYN（ack=x+1），同时自己也发送一个SYN包（seq=y），即SYN+ACK包，此时服务器进入SYN_RCVD状态；
第三次握手：客户端收到服务器的SYN+ACK包，向服务器发送确认包ACK（ack=y+1），此包发送完毕，客户端和服务器进入ESTABLISHED状态，完成三次握手。
一些知识点：
前两次握手虽然占用了seq（序列）号，但是并不发送数据，所以回复ack（确认）号时只是加一，相当于占用了一个seq号，但是并不使用，第三次握手时就可以传送数据了。
2、为什么需要三次握手才能建立连接
答案：
主要是为了初始化Sequence Number（序列号）的初始值，通信的双方要互相通知对方自己初始化的Sequence Number，也就是上图中的x和y，这个号要作为以后的通信的序号，以保证应用层接受到的数据不会因为网络上的传输问题而乱序，即TCP会用这个序号来拼接数据，因此在服务器发回它的Sequence Number及第二次握手之后，客户端还需要发送确认报文给服务器，告诉服务器，客户端已经收到你的初始化的Sequence Number了。
3、首次握手的隐患——SYN超时
问题起因分析：
服务器收到客户端的SYN，回复SYN-ACK的时候未收到ACK确认，服务器不断重试直至超时，Linux默认等待63秒才断开连接，这就可能会导致服务器遭到SYN Flood攻击，恶意程序会给服务器发一个SYN报文，发完后就不管了，但是服务器需要63秒才会断开这个连接，这样攻击者就可以把服务器的SYN连接队列耗尽，让正常的连接请求不能处理。
问题的解决办法：
Linux下在SYN队列满后，通过tcp_syncookies参数回发SYN Cookie，若为正常连接则客户端会回发SYN Cookie，直接建立连接。
更多的了解一下SYN Cookie：戳我一下
4、建立连接后，客户端出故障怎么办
答案：
保活机制：像客户端发送一个保活探测报文，如果未收到响应则等待一个提前设置好的保活时间间隔后，继续发送保活探测报文，直到尝试次数达到保活探测数且仍未收到响应则中断连接。
5、谈谈TCP的四次挥手
TCP四次挥手的流程图如下：
答案：
TCP采用四次挥手来释放连接
第一次挥手：客户端发送一个FIN，用来关闭客户端到服务器的数据传送，客户端进入FIN_WAIT_1状态；
第二次挥手：服务器收到FIN后，发送一个ACK给客户端，确认序号为收到的序号+1（与SYN相同，一个FIN占用一个序号），服务器进入CLOSE_WAIT状态；
第三次挥手：服务器发送一个FIN，用来关闭服务器到客户端的数据传送，服务器进入LAST_ACK状态；
第四次挥手：客户端收到FIN后，客户端进入TIME_WAIT状态，接着发送一个ACK给服务器，确认序号为收到的序号+1，服务器进入CLOSED状态，完成四次挥手。
6、为什么四次挥手会有TIME_WAIT状态，且时间为2MSL
答案：
1、确保有足够的时间让对方收到ACK包
2、避免新旧连接混淆
更多相关内容：Time-wait状态(2MSL)一些理解
7、为什么需要四次挥手才能断开连接
答案：
因为TCP连接是全双工的，所以发送方和接收方都需要FIN报文和ACK报文，所以发送方和接收方各自需两次挥手。
8、服务器出现大量CLOSE_WAIT状态的原因
答案：
1、可能是服务器代码的释放资源部分出现了问题
2、可能是处理请求的线程配置出现了问题
9、UDP与TCP的区别
UDP的特点：
1、面向非连接
2、不维护连接状态，支持同时多个客户端传输相同的信息
3、数据包报头只有8个字节，额外开销较小
4、吞吐量只受限与数据生成速率、传输速率以及机器性能
5、尽最大努力交付、不保证可靠交付，不需要维持复杂的链接状态表
6、面向报文，不对应用程序提交的报文信息进行拆分或者合并
TCP和UDP的区别：
10、TCP的拥塞控制、可靠传输、流量控制
这一部分的内容就比较复杂了，推荐大家可以看看B站上的王道考研计算机网络的视频，小姐姐讲的非常清楚，这里是链接：王道考研—计算机网络
11、在浏览器键入URL，按下回车之后经历的流程
图解（图片来源：《图解HTTP》）：
另外还有一篇解释的很详细的文章：前端经典面试题: 从输入URL到页面加载发生了什么？
12、常见的HTTP状态码
5种可能的取值：
常见状态码：
| 状态码 | 含义 |
|---|---|
| 200 | 正常返回信息 |
| 400 | 客户端请求有语法错误 |
| 401 | 请求未经授权，这个状态码必须和WWW-Authenticate报头域一起使用 |
| 403 | 服务器收到请求，但是拒绝提供服务 |
| 404 | 请求资源不存在 |
| 500 | 服务器出现错误 |
| 503 | 服务器当前不能处理客户端请求，一段时间后可能回复正常 |
13、GET请求和POST请求的区别
从三个层面来解答
1、HTTP报文层面：GET将请求信息放在URL后面，请求信息和URL之间用问号隔开，请求信息的格式为键值对。POST放在报文体中，想获得信息必须解析报文，因此安全性较GET方式更好一些。事实上，要想获得报文体中的信息也是非常容易的，因此在安全性上，两者并没有太大的区别，具体解决传输过程中的安全问题还要靠HTTPS。
由于GET请求的信息放在URL中，因此是有长度限制的，因为虽然URL本身是没有长度限制，但是各种浏览器会对URL的长度做出限制。POST中的请求信息是放置在报文体中的，因此对于数据长度是没有限制的。
2、数据库层面：GET符合幂等性和安全性，POST不符合。幂等性就是对数据库的一次操作和多次操作获得的结果是一致的。安全性就是对数据库的操作没有改变数据库中的数据。GET操作是做查询操作的，因此不会改变数据库中原有的数据，大致可以认为是符合安全性和幂等性的。POST请求方式是既不幂等也不安全的，因为POST请求往往会向数据库中提交数据，因此会改变数据库中的数据，其次POST请求方式每次获得的结果都有可能不一样，因为POST请求是作用在上一级的URL上的，每一次请求都会添加一份新资源，这也是POST和GET方式最大的区别。
3、其他层面：GET可以被缓存、被存储，GET请求会保存在浏览器的浏览记录中，以GET请求的URL能够保存为浏览器书签，而POST不行。
14、Cookie和Session的区别
答案：
1、Cookie数据存放在客户的浏览器上，Session数据存在服务器上
2、Session相对于Cookie更安全
3、若考虑减轻服务器负担，应当使用Cookie
15、HTTP和HTTPS的区别
答案：
1、端口 ：HTTP的URL由http://起始且默认使用端口80，而HTTPS的URL由https://起始且默认使用端口443。
2、安全性和资源消耗： HTTP协议运行在TCP之上，所有传输的内容都是明文，客户端和服务器端都无法验证对方的身份。HTTPS是运行在SSL/TLS之上的HTTP协议，SSL/TLS 运行在TCP之上。所有传输的内容都经过加密，加密采用对称加密，但对称加密的密钥用服务器方的证书进行了非对称加密。所以说，HTTP 安全性没有 HTTPS高，但是 HTTPS 比HTTP耗费更多服务器资源。
总结
一篇文章不可能收录所有的面试题，最重要的还是要对计算机网络有一定的了解。
