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协议的要求，只是理论上最小值。

TCP三次握手的时候，Linux内核维护两个队列，一个是SYN队列一个是accepet队列。

异常情况：

1. TCP第一次握手丢失SYN包，即客户端发起SYN，一直没有收到服务器的ACK，所以会一直超时间重传，每次时间RTO指数级别上涨，当超过最大重传次数后，客户端不发送SYN包。
2. TCP第二次握手丢失SYN、ACK包，客户端接受不到SYN、ACK，客户端超时间重发SYN，服务端超时重传SYN、ACK包，直到最大重传次数。
3. TCP第三次握手丢失ACK包，服务器端重传SYN、ACK超过最大重传次数就断开TCP连接，客户端向服务端发送数据包所以一直超时重传，超过最大重传次数（连接后的次数不一样），如果不发送数据就会一直处于established状态，直到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协议以及HTTP协议优化策略思路

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

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

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

HTTP1.1 支持管道网络传输，只要第一个请求发出就不用等他回来，可以发第二个请求。

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

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

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

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

优化策略思路：

1. 避免发送HTTP请求----通过本地缓存的方式
2. 在需要发送HTTP请求的时候减少HTTP请求的发送次数
   1. 减少重定向请求次数-----将重定向的工作交给代理服务器完成
   2. 合并请求---请求大资源来代替小资源
   3. 延迟发送请求---只获取用户目前需要看到的页面内容
3. 减少HTTP响应的数据大小----压缩

6:HTTPS协议

1. 混合加密（非对称加密（建立通信前）+对称加密的方式（通信中））---提高速度
2. 摘要算法（指纹+明文的加密）-----证明数据是完整的
3. 数字证书（服务器公钥存放在机构里面）-----保证公钥不被篡改

先完成TCP连接的建立，然后走TLS握手的过程

TLS四次握手过程

1. Client Hello   TLS版本号、支持密码的套件列表、随机数
2. Server Hello 服务器确定的TLS版本好、密码套件、随机数  Server Certificate  数字证书 Server Hello Done
3. Client Key Exchange 生成一个随机数pre-master，根据已经得到的三个随机数生成会话密钥（对称密钥）--->进行加密--->生成数据摘要
4. 服务器进行同3一样的操作验证加密与解密没有问题

7:TCP重传、滑动窗口、流量控制、拥塞控制

[1] 超时重传（RTT）、快速重传、SACK

[2] 滑动窗口----无需等待确认应答，而可以继续发送数据的最大值

[3] 流量控制

[4] 拥塞控制  慢启动算法（指数级别）拥塞避免（线性增长）拥塞发生（拥塞窗口重置为1）快恢复（缩小一半）