计算机网络面试问题
1. 网络七层 和 TCP/IP 四层结构
1.1 物理层：透明比特流传输，忽略不同设备之间的差异
1.2 数据链路层：将物理层数据封装成帧
1.3 网络层：路由操作，IP协议所在层
1.4 传输层：TCP和UDP所在的一层
1.5 会话层：建立设备之间的连接，https中SSL所在层
1.6 表示层：将上面的数据表示为计算机可以理解的，包括数据的压缩解压等等
1.7 应用层：进程之间的通信
2. IP数据报的数据结构
3. TCP 和 UDP 的数据结构
3.1 原始端口：16bit，说明的是，发送者的端口号，范围是 0-65535
3.2 目的端口：16bit，说明的是，接收者的端口号，范围是 0-65535
3.3 数据序号：seq 是当前发送数据的序号，是数据的第一个字节的序号，假设该序号是 x
3.4 确认序号：ack 是确认发送者发来的数据的序号，如果数据序号是 x，那么下次确认时，给发送者发过去的确认序号ack=x+1
3.5 偏移：
3.6 保留：未使用
3.7 U：URG，紧急字段，值为1 表示为紧急包，应当在网络中优先传输
3.8 A：ACK，确认序号，值为1，当前数据包有效
3.9 P：PSH
3.10 R：RST，值为1时表示TCP连接出错，应当重连
3.11 SYN：值为1时表示发起三次握手或者确认三次握手，（只在前两次握手时 SYN=1）
3.12 FIN：值为1表示该包是关闭连接请求包
3.13 窗口字段：控制对方发送的流量窗口
3.14 包校验和：
3.15 紧急指针：
3.16 可选选项：
3.17 填充：
3.18 用户数据：用户的数据
4. 网络包封装分析
5.三次握手
5.1 客户端 置 SYN=1，且当前 数据序号是 x
5.2 服务端 接收到，返回的数据包，置 SYN=1，且当前数据序号是 y，且检查客户端的数据序号并生成确认序号 ack=x+1，且ACK=1 表示当前包有效
5.3 客户端再次接收到数据包，此时 SYN=0（已经不再重要），检查服务器数据序号并生成确认序号 ack=y+1，且当前数据序号为 x+1，ACK=1
5.4 为什么不是两次握手：如果是两次握手就建立了连接。假设，客户端发送了第一次请求，但是由于网络问题，这次请求在网络中滞留了，且客户端迟迟得不到服务端发来的确认包，客户端就认为，这个包没有传递给服务端，因此又重新发一次请求。但是，随后服务端接收到了第一次的请求包，并给予客户端确认。但是客户端的第二次请求包又到达了服务端，这时服务端认为一个新的连接请求来了，这样就导致了更多的问题。其实，我觉得三次握手就像是在修复 TCP/IP协议数据结构的bug，如果TCP/IP数据结构再详细一些，那么可能就不需要三次握手了。
6.四次挥手
6.1 客户端请求关闭，发送 FIN=1的数据包，且当前的数据序号为 u
6.2 服务端接收到了这个数据包，但是可能服务端要给客户端传递的数据还没有完成，现在接着给客户端传数据，ACK=1，seq=v，ack=u+1
6.3 服务端已经给客户端传递完了所有数据，现在发送确认关闭包，FIN=1，seq=w，ACK=1，ack=u+1（不变）
6.4 客户端接收到了服务端的确认关闭包，ACK=1，seq=u+1，ack=w+1
6.5 此时客户端进入 TIME-WAIT，等待两个报文时间，因为在发送完最后一个ACK=1包时，至少且最多经过两个报文时间，所有的这次四次握手的包会在网络中彻底消失
7.在浏览器中输入一个网址的时候，发生了什么
7.1 首先输入网址
7.2 因为输入的是网址，而不是IP，因此浏览器会先查找缓存，有没有网址对应的IP
7.2.1 查找的缓存有：浏览器缓存的DNS；系统缓存（host）文件里面的映射；路由器缓存；ISP缓存，递归搜索等等
7.3 浏览器给web服务器发送一个http请求（GET）
7.4 服务器给出一个正确的重定向地址，规定了要访问的正确的URL
7.5 浏览器发送另一个正确请求（GET）
7.6 服务器处理请求
7.7 返回HTML响应
7.8 浏览器显示HTML内容
7.9 浏览器扫描到内嵌HTML对象，例如CSS，图片等，每遇到一个这种对象，都要重新发送GET请求获取
7.10 浏览器发送异步请求
8.滑动窗口
8.1 滑动窗口包含发送窗口和接收窗口
8.2 1比特窗口协议：它退化为了停止等待协议，当1个比特传输失败，没有收到对方的确认帧，停止当前进程，重传这个数据
8.3 后退n协议，发送窗口发送一帧不停下来，而是继续发送，并对每帧都设置一个计时器，且连续发送若干帧，当某帧超时没收到对方的确认帧，那么后退到这个失效帧，重新再发送这若干个帧。这种方式的效率不一定高于停止等待协议，因为如果发送窗口大小为k，接收窗口大小为1，那么发送窗口就会造成资源浪费。（当网络传输质量差时）
8.4 选择重传协议，某帧出错，先暂时不管，继续发送后面的帧，但是接收方必须设置一个缓冲区，存后面发来的帧，当这个失效帧成功传过来，再将缓冲区的帧拿出来，这要求接收方要有一定的缓冲空间。
