【准备面试】前端个人知识梳理（二）计网

二 计网

• TCP/IP模型分层

• 键入网址到网站加载出来的全流程（DNS=>TCP=>HTTP=>IP/数据链路层分发）

• HTTP状态码

• HTTP常见字段

• HTTP两种缓存

• HTTP1.0/1.1/2.0/3.0

• HTTPS特性和连接过程

• TCP三次握手和四次挥手
  1.三次握手
  SYN => SYN+ACK => ACK
  前两次不能带数据 第三次才能
  三次握手是为了防止旧的重复连接初始化造成混乱，避免资源浪费，还可以同步双方初始序列号（很好理解RST），所以不能两次握手，并且四次握手就不需要了，可以合并为三次握手
  – 每次建立连接时，初始化的序列号要求都不一样，否则很容易出现历史报文被下一个相同四元组接收的问题
  – ISN = 计时器M+哈希算法F
  – 如果一个IP分片丢失，整个IP报文都要重传，非常没效率，因为IP层没有超时重传机制，因此TCP需要先把数据按MSS分片，这样被IP层封装之后大小也不会超过MTU，即使TCP分片丢失，重发也是以MSS为单位
  – 第一次SYN丢失：客户端超时重传SYN：RTP=>2RTO=>4RTO=>8RTO
  – 第二次SYN+ACK丢失：客户端和服务器都要超时重传，时间同上，注意都有最大重传次数做限制
  – 第三次ACK丢失：注意是服务器重传SYN+ACK，客户端的ACK不会重传，其余同上
  – SYN攻击和应对策略（增大tcp半连接队列，使用tcp_syncookies，减少SYNACK的重传次数以加快TCP连接断开等）
  2.四次挥手
  FIN=>ACK FIN=>ACK
  因为服务端通常需要等待数据的发送和处理，所以服务端的ACK和FIN一般都会分开发送，所以需要四次挥手
  – 第一次FIN丢失，客户端超时重传FIN（同上）
  – 第二次ACK丢失，客户端超时重传FIN，服务端ACK不重传，其余同上
  – 第三次FIN丢失，服务器超时重传FIN，如果没收到客户端第四次挥手ACK，断开，或者客户端等待时长超过了FIN_WAIT_2状态的时长，也会断开，其余同上
  – 第四次ACK丢失，服务器超时重传FIN，其余同上，或者客户端每次收到服务器的第三次FIN时都会重置TIME_WAIT状态下的2MSL计时器，客户端等2MSL没有收到FIN的话，也断开
  – MSL：报文最大生存时间，TIME_WAIT状态的目的是为了让两个方向上的数据包都能被丢弃，保证新的数据包一定都是新链接所产生的，没有上次连接的残余，将TIME_WAIT设为2MSL可以允许一次丢包（第四次ACK丢失），因为报文来回一次时间恰好就是2MSL
  – TIME_WAIT过多会占用系统/端口资源
  – HTTP没有使用长连接=>客户端或者服务器至少有一方没有设置keep-alive=>服务端制动关闭连接=>服务端出现大量TIME_WAIT，此外HTTP长连接超时，或者HTTP长连接请求数量达到上限都会使服务端主动断开连接
  – 如果服务端出现大量CLOSE_WAIT，一般是代码问题，导师服务端没有调用close()函数，从而发不出FIN报文
  – 建立连接后客户端突然故障=>TCP保活机制 服务端故障（比如被kill）=>服务端会发送FIN，和客户端进行四次挥手
  – TCP的socket编程有两种socket：监听socket和已完成连接socket，客户端connect成功返回是第二次握手，服务端accept成功返回是在第三次握手之后，没有listen和accept，都能建立TCP连接

• TCP重传/滑动窗口/拥塞控制/流量控制
  以下的内容，都是在数据传输过程
  – 超时重传：RTO应该略大于RTT，两者都是动态变化的，RTO存在时间加倍机制，RTO=>2RTO.>…
  – 快速重传：服务器给客户端连发三个ack，表示我还没收到xxx，但是可能会存在重传一个还是重传全部的问题
  – SACK（选择性确认）重传：在快速重传的基础上，服务端附带返回SACK，告诉客户端哪些数据收到了
  – D-SACK：使用SACK告诉发送方哪些数据被重复接收了
  – 发送方的滑动窗口4部分，接收方3部分，两边大小是约等于的关系，通常发送方的窗口大小由接收方决定，SND.UNA,SND.NEXT,RCV.NEXT,SND.WND,RCV.WND，其实就是，发送端收到了接收端的ACK之后，窗口右移，而接收端收到数据之后窗口直接右移，注意窗口可能会因为接收端特别繁忙而压缩甚至到0（缓冲区问题），这时候发送方的窗口也要适时调整
  – TCP规定，不能同时减少缓存又收缩窗口，而先收缩窗口，过段时间再减少缓存，这样可以避免丢包
  – 窗口探测报文：发送方收到0窗口通知之后，开一个定时器，定时器超时后（比如接收方窗口变大的通知报文丢失），发送方会发窗口探测报文（一般探3次）
  – 初始接收窗口 - 缓冲区剩余 -【操作系统减少的接收缓存】 = 改变之后的接收窗口
  – 接收方窗口小于min（MSS,1/2）缓存时，直接向发送方通告窗口为0，发送方通常使用Nagle算法避免发送小数据，两边同时满足条件才能避免小窗口现象
  – 考虑拥塞窗口，swnd=min(cwnd,rwnd)，发生了超时重传，就认为网络中发生了拥塞
  – 慢启动：理解图表中的cwnd=1就是指一次能发送1MSS数据，轮次=0时，cwnd=1，然后呈倍数增长直到ssthresh（每收到一个ack，cwnd+1）
  – 拥塞避免：在到达ssthresh后，每收到一个ack，cwnd+1/cwnd（线性增加，每收到一个ack加1/cwnd）
  – 拥塞发生之后：超时重传=>ssthresh = cwnd/2 , cwnd => 重置为cwnd初始化值（假设为1），这个不太好
  – 更好的是快速重传+快速恢复：cwnd = cwnd/2 , ssthresh = cwnd , cwnd = ssthresh +3（+3表示已经收到了快速重传的3个ack），然后cwnd每收到一个重复的ack就+1直到客户端收到新数据的ack为止（这一步其实是为了把丢掉的包尽快发过去，+1代表每个收到的重复ack包都已经离开了网络），然后cwnd = ssthresh，重新进入拥塞避免流程。

• TCP和UDP的对比
  1.TCP需要连接 UDP不需要
  2.TCP只能一对一
  3.TCP可靠，UDP尽力交付，但是QUIC是可靠的
  4.TCP有流量控制拥塞控制 UDP没有
  5.头部开销TCP至少20B，UDP8B
  6.TCP是流式传输，没有边界，UDP按数据包发送有边界
  7.TCP大于MSS在传输层开拆，UDP大于MTU在IP层开拆
  因此TCP => HTTP/HTTPS/FTP，UDP=>DNS/广播/多媒体通信
  TCP和UDP可以使用同一个端口，因为内核软件模块是独立的

• IP知识和ping原理

• 常见安全问题
  – XSS跨站脚本，攻击者直接向web页面里写入恶意Script代码，客户端或者服务端必须对输入做验证，禁止JS读取某些敏感的cookie，加验证码，WEB应用端对值做充分转义等，过滤一些敏感字符
  – CSRF跨站请求伪造，A网站对用户建立信任关系之后，在B网站利用这种信任关系向A发起位置哦啊的用户操作请求，应该加入token验证，对token加密，或者把token隐藏于表单之中，或者后盾验证源referer
  – SQL注入，比如“password or 1=1”，前后端均需验证用户的输入，或者后端使用参数化的查询语句
  – 点击劫持，比如透明恶意小广告iframe，点关闭没用反而变成全屏，可以用X-FRAME-OPTIONS这个http请求头对网站进行筛选，避免点击劫持

• Session/token机制

---