文章目录
- 七层网络模型和五层网络模型， 以及各自都有哪些常见协议？
- TCP、UDP对比，使用选择
- TCP为什么可靠、UDP怎样才能可靠
- 扩展考察点： QUIC 协议
- TCP、UDP报文头部格式
- TCP三次握手挥手四次挥手过程
- 扩展： TCP两次握手
- SYN泛洪攻击原理及解决方案
- 为什么要等待2MSL（time_wait用处）
- 服务方大量close_wait状态原因及解决方案
- HTTP请求响应报文格式
- HTTPS连接过程
- HTTP & HTTPS 比较
- 常见HTTP状态码
- HTTP历史版本变化
- cookie & session 作用和区别
- DNS递归和迭代查询(应用层)
- IO多路复用SELECT， POLL， EPOLL对比
- tcp三次握手，第一次握手如果服务器不响应会发生什么：
- PING实现原理
七层网络模型和五层网络模型， 以及各自都有哪些常见协议？
物理层
链路层
网络层：ARP， IP， ICMP
传输层：TCP UDP
会话层 |
表示层 | --- HTTP SMTP POP SSL FTP
应用层 |
TCP、UDP对比，使用选择
a. TCP是面向连接的可靠数据传输服务，UDP则提供无连接的不可靠数据传输服务
b. TCP只支持点到点的数据传输服务， UDP支持一对一、一对多、多对一、多对多交互通信
c. TCP有拥塞控制、流量控制； UDP没有拥塞控制
d. TCP首部开销大，20字节，UDP首部开销小，8字节
e. TCP报文长度是动态的，有接收方窗口大小和当前网络拥塞情况决定； UDP面向报文，不合并，不拆分，保留上面传下来报文的边界
选择：需要数据完整可靠：TCP； 需要通信实时性：UDP
TCP为什么可靠、UDP怎样才能可靠
为什么可靠：校验和、序列号和确认应答、超时重传、流量控制、拥塞控制。
UDP怎么实现：参照tcp在应用层模仿可靠性传输机制
1、添加seq/ack机制，确保数据发送到对端
2、添加发送和接收缓冲区，主要是用户超时重传。
3、添加超时重传机制
扩展考察点： QUIC 协议
TCP、UDP报文头部格式
https://zhuanlan.zhihu.com/p/40013850
TCP三次握手挥手四次挥手过程
https://zhuanlan.zhihu.com/p/40013850
扩展： TCP两次握手
最后一次应答可以直接带数据了， 所以可以看成只需要两次握手
SYN泛洪攻击原理及解决方案
攻击者发送TCP的SYN，服务器返回ACK后，该攻击者就不对其进行确，那么这个TCP连接处于挂起状态。攻击者如果发送非常大量的这种TCP连接，服务器消耗CPU和内存，最后服务器可能死机，就无法为正常用户提供服务。
当服务器接收到一个SYN报文段时，服务器不会为该报文段生成一个半开的连接 ，而是哈希映射记录其身份信息。如果客户合法，则会返回ACK报文，再建立套接字连接。
为什么要等待2MSL（time_wait用处）
等待2MSL时间主要目的是怕最后一个ACK包对方没收到，那么对方在超时后将重发第三次握手的FIN包，主动关闭端接到重发的FIN包后可以再发一个ACK应答包。
在TIME_WAIT状态时两端的端口不能使用，要等到2MSL时间结束才可继续使用。当连接处于2MSL等待阶段时任何迟到的报文段都将被丢弃。不过在实际应用中可以通过设置SO_REUSEADDR选项达到不必等待2MSL时间结束再使用此端口。
如果TIME_WAIT状态保持时间不足够长，第一个连接就正常终止了。第二个拥有相同五元组的连接出现，而第一个连接的重复报文到达，干扰了第二个连接。TCP事先必须防止某个连接的重复报文在连接终止后出现，所以让TIME_WAIT状态保持时间足够长(2MSL)，连接相应方向的上的TCP报文要么完全响应完毕，要么被丢弃。建立第二个连接的时候，不会混淆。
服务方大量close_wait状态原因及解决方案
出现大量CLOSE_WAIT的原因很简单，就是某一方在网络连接断开后，没有检测到这个错误，没有执行closesocket，导致了这个状态的实现
HTTP请求响应报文格式
请求行--首部行--空行--实体行
状态行--首部行--空行--实体行
HTTPS连接过程
a. 客户端请求建立SSL连接，把自己支持的加密规则发送给网站
b. 网站选择一组加密算法和hash算法，把自己身份信息以证书形式发回给客户端，其中证书信息包含（网站地址、加密公钥、证书颁发机构等）
c. 客户端获取证书后
i. 验证证书合法性
ii. 生成一串随机数作为密码（对称密钥），并使用公钥进行加密
iii. 使用约定好hash计算握手消息
iv. 使用对称密钥对消息进行加密，并把信息发送给网站
d. 网站接收到消息后
i. 使用私钥解密，取出对称密钥
ii. 使用对称密钥解密握手消息，并验证hash是否一致
iii. 使用对称密钥加密一段握手消息发送给游览器
e. 游览器解密并验证hash验证，如果hash一致，则握手结束
f. 双方使用对称加密算法进行数据加密、传输
HTTP & HTTPS 比较
1. 安全性： 明文 --- SSL/TSL加密传输
2. 端口： 80 --- 443
3. HTTPS在TCP三次握手后，还需要进行SSL握手，协商对称加密秘钥
4. HTTPS需要申请服务端证书
常见HTTP状态码
lxx:指示信息--表示请求已接收,继续处理
2xx:成功--表示请求已被成功接收、理解、接受。
3xx:重定向--要完成请求必须进行更进一步的操作。
4xx:客户端错误--请求有语法错误或请求无法实现。
5xx:服务器端错误--服务器未能实现合法的请求。
301 moved permanently (永久重定向)
302 move temporarily(临时重定向)
403 Forbidden:服务器收到请求，但是拒绝提供服务。
HTTP历史版本变化
HTTP/0.9：功能简陋，只支持GET方法，只能发送HTML格式字符串。
HTTP/1.0：支持多种数据格式，增加POST、HEAD等方法，增加头信息，每次只能发送一个请求（无持久连接）
HTTP/1.1：默认持久连接、请求管道化、增加缓存处理、增加Host字段、支持断点传输分块传输等。
HTTP/2.0：二进制分帧、多路复用、头部压缩、服务器推送
cookie & session 作用和区别
1. 存储格式：Cookie 只能保存 ASCII， Session 可以存任意数据类型
2. 有效期：Cookie 可设置为长时间保持，比如我们经常使用的默认登录功能，Session 一般失效时间较短，客户端关闭或者 Session 超时都会失效。
3. 隐私策略：Cookie 存储在客户端，比较容易遭到不法获取；Session 存储在服务端，安全性相对 Cookie 要好一些。
4. 大小限制：单个 Cookie 保存的数据不能超过 4K；Session 可存储数据远高于 Cookie。
DNS递归和迭代查询(应用层)
a. 从主机到本地dns服务器为递归查询
b. 其余查询皆为迭代查询（根域名-顶级域名-二级域名-三级域名-四级域名、、、--权威名称服务器
IO多路复用SELECT， POLL， EPOLL对比
事件集，最大支持文件描述符数，工作模式，具体实现四个方面对比
1. 事件集合：
1. fd和事件分离，每次需重置三个参数（读，写，异常）集合
2. fd和事件绑定
3. 在内核维护一个事件表
2. 支持FD数：
1. 默认低于1024
2. 系统最大允许65535
3. 系统最大允许65535
3. 工作模式：
1. LT
2. LT
3. LT(Level Trigger) / ET(Edge Trigger)
4. 具体实现：
1. 轮询o(n)
2. 轮询o(n)
3. 回调o(1)
Epoll_wait适用于连接数多，但活动连接较少的情形，避免回调函数被频繁触发。
tcp三次握手，第一次握手如果服务器不响应会发生什么：
超时时间由重传超时时间（默认1秒钟（1*HZ））和重传次数TCP_SYNACK_RETRIES（默认5次）决定。现象如下：
SYN无响应，隔1s，重传第1次，再隔2s，重传第2次，再隔4s，重传第3次，再隔8s，重传第4次，再隔16s，重传第5次，再隔32s，超时重传次数到了，断开链接。
https://blog.csdn.net/xuhao07/article/details/100037712
PING实现原理
互联网控制消息协议ICMP (Internet Control Message Protocol)
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
