C++秋招（暑期实习）准备---5--- 计算机网络

C++秋招（暑期实习）准备---5--- 计算机网络

1:浅谈浏览器输入URL发生了什么？

开放性回答

思路1:

DNS->正向代理->反向代理->.... 从缓存机制角度思考

思路2:

1.  HTTP协议针对目标Web服务器生成HTTP请求报文message
2. TCP协议将HTTP报文进行分割成segment，并在各个报文上打上标记序号及端口号后转发给网络层
3. IP协议增加dst IP地址,并将报文段分装成packet传送，转发给链路层frame
4.  接收端 相似

2:浅谈UDP和TCP的区别

1. TCP需要一对一稳定的连接，UDP无连接，可以一对多
2. TCP可靠传输，Seq，Ack，超时重传，UDP不可靠
3. TCP是字符流传输，UDP是报文传输

3:TCP三次握手为什么不是两次 以及四次挥手

第一次握手：建立连接时， 客户端发送 syn包（syn=j）到 服务器，并进入 SYN_SENT状态，等待服务器确认；SYN：同步序列编号（ Synchronize Sequence Numbers）

第二次握手：服务器收到syn包，必须确认客户的SYN（ack=j+1），同时自己也发送一个SYN包（syn=k），即SYN+ACK包，此时服务器进入SYN_RECV状态。

第三次握手：客户端收到服务器的SYN+ACK包，向服务器发送确认包ACK(ack=k+1），此包发送完毕，客户端和服务器进入ESTABLISHED（TCP连接成功）状态，完成三次握手。

三次握手的目的是为了防止已经失效的连接请求报文突然又传到服务器，因而产生错误。

例如：客户端A发出去的第一个连接请求报文没有丢失，而因为某些原因滞留在了某个网络节点上，导致延迟到了连接释放以后的某个时间段又到达服务器B，但本来这是一个失效的报文，但是B收到这个失效的报文，以为A重新发了一个新的连接请求，于是B就向A发送确认报文，表示同意连接。如果不是三次握手，那么就B发出报文就是确认连接嘛，B就一直等待接受数据，会浪费很多资源。如果是三次握手就不会出现这种情况，B收到一个失效的报文向A确认，但A并没有要建立连接，于是就不会向B端确认。

本质：信道是不可靠的，但是我们要建立可靠的连接发送可靠的数据。并不是TCP协议的要求，只是理论上最小值。

四次挥手：

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

（2） 服务器收到这个FIN，它发回一个ACK，确认序号为收到的序号加1。和SYN一样，一个FIN将占用一个序号。（保证2-3阶段服务器数据传输完毕）

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

（4） 客户端发回ACK 报文确认，并将确认序号设置为收到序号加1。客户端进入close_wait状态(为了保证客户端最后一个ACK报文段能够到达服务器）

4:浅谈TCP粘包现象

因为TCP是一个字符流传输，在进行数据传输是我们连续调用send分别发送两段数据data1和data2，会出现以下情况：

1. 先接收到data1，然后接收到data2。
2. 先接收到data1的部分数据，然后接收到data1余下的部分以及data2的全部。
3. 先接收到data1的全部数据和data2的部分数据，然后接收到data2余下的数据。
4. 一次性接收到了data1和data2的全部数据。

产生原因：其中234为粘包现象 Nagle算法造成发送端粘包，接收端接受不及时造成的接收端粘包

解决办法：对数据包进行封包和解包

5:HTTP协议

HTTP1.1 支持长连接 来弥补 HTTP1.0每次请求都要创建连接的缺点。

HTTP1.1 在请求头中引入range头域，优化了带宽浪费，并且能支持断点续传。

HTTP1.1 支持Host头域，解决在一台物理服务器上存在多个虚拟主机的问题

HTTP2.0 多路复用，由于长连接复用Pipeling是简单串形化，会导致队头阻塞，多路复用可以在使得多个请求在一个连接上并行执行。

HTTP2.0 服务器推送，能把所需要的资源带着index.html一起发送到客户端去，省去客户端重复请求到步骤。

HTTP2.0 头部压缩，由于cookie的膨胀导致header进行压缩。

HTTP2.0 二进制分帧，在HTTP/2和TCP之间加入二进制分帧层，使用二进制编码，改变了原本机遇文本协议的格式解析方式，更加方便和健壮。

6:HTTPS协议

HTTPS采用对称密钥加密与非对称密钥加密两种方式混合加密。