1.应用层
1.1HTTP的头部字段
（1）HTTP请求
GET http://www.example.com/ HTTP/1.1
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9
Accept-Encoding: gzip, deflate
Accept-Language: zh-CN,zh;q=0.9,en;q=0.8
Cache-Control: max-age=0
Host: www.example.com
If-Modified-Since: Thu, 17 Oct 2019 07:18:26 GMT
Connection: keep-alive
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 xxx
param1=1¶m2=2
- Cache-control：表示对缓存的策略，客户端和服务器都有这个标记。
- no-cache：不使用缓存
- no-store：不保存到缓存
- If-Modified-Since：浏览器中所存的页面的最后时间，会随HTTP请求发送过去，如果服务器上面的页面修改时间与之相同，则会给予一个304响应，且不带数据，否者就会把新的页面传输过来，状态码为200.
- Connection：保持连接
(2)HTTP响应
HTTP/1.1 200 OK
Age: 529651
Cache-Control: max-age=604800
Connection: keep-alive
Content-Encoding: gzip
Content-Length: 648
Content-Type: text/html; charset=UTF-8
Date: Mon, 02 Nov 2020 17:53:39 GMT
Etag: "3147526947+ident+gzip"
Expires: Mon, 09 Nov 2020 17:53:39 GMT
Keep-Alive: timeout=4
Last-Modified: Thu, 17 Oct 2019 07:18:26 GMT
Proxy-Connection: keep-alive
Server: ECS (sjc/16DF)
Vary: Accept-Encoding
X-Cache: HIT
<!doctype html>
<html>
<head>
<title>Example Domain</title>
// 省略...
</body>
</html>
- Cotent-Lenth：表示要传输文件的总大小 如何判断服务器是否发完全部数据
- Etag：验证是否是原信息
（3）keep-alive一定会使用长连接吗
不一定，客户端和服务器都可以无视这个值，尤其是如果只有小文件时候。
1.2请求有哪几种，有什么区别
（1）HEAD
客户端可能只需要服务器给出响应头部即可
（2）GET
-
请求某个url的资源，不会对服务器端数据进行修改，相当于数据库的查。
-
具有的特性 幂等性，即一次操作和多次操作的结果相同
-
参数放置于头部，可能会被缓存到浏览器，不安全
（3）POST
- 提交某部分信息，可能会对服务器的数据进行修改
- 提交的数据放置于请求体中，安全
（4）DELETE
- 对url的资源进行删除
（5）UPDATE
- 对url的资源进行更新
1.3 三次握手
1.3.1 三次握手的过程
1.3.2 为什么需要三次握手，两次不行吗？
不行
假设只需两次握手。
在客户端发送请求，服务器接收到请求后，服务器发起第二次请求，发完之后服务器认为它已经握手成功，而此时第二次握手信息在传输过程中丢失。
而服务器之后一直给客户端发送信息，而客户端因为并没有得知服务器的序列号而无法接收信息。
1.3.3 SYN Flooding是什么，如何处理？
是什么：服务器不断收到第一次SYN请求，并给它分配空间，而导致空间已满不能给另外的TCP请求分配空间而导致 拒绝服务。
处理方法：TCP Cookie，服务器收到第一次握手后，并不给客户端分配空间。
1.3.4 为什么发送方第一次握手不能发送信息？接收方不能先缓存吗？
不能，因为这样会放大SYN Flooding攻击，最终导致拒绝服务。
1.4 四次挥手
1.4.1四次挥手的过程
1.4.2 为什么需要四次挥手，三次不行吗？
不行，TCP是全双工的，当某一方想关闭连接时，另一方可能还有数据需要发送，所以每次只能关闭一个方向的发送。
1.4.3 为什么等待时间是2MSL
-
可靠实现TCP全双工连接的终止
该时间其实应该为一个重传时间（被动关闭段重传）+一个MSL（被动端重传的报文最大传输时间）
-
why ？
因为假设最糟糕的情况是被动关闭端第一次发送的FIN 瞬间到达关闭端，此时第四次挥手发生，然后挥手报文丢失。经过一个重传时间，发送第二个FIN，然后再加上一个最大传输时间
-
-
保证这次连接的重复数据段从网络中消失（根据时长可以判断此为主要原因。
- 这主要是为了避免前后两个使用相同四元组的连接中的前一个连接的报文干扰后一个连接。
- 第一个MSL是让第四次挥手的发送方的报文消失在链路中
- 第二个MSL是让第四次挥手的接收方的FIN请求消失在链路中（因为接收方会在LAST-ACK状态中持续不断地发送 FIN请求）
因为在传输过程中，可能会丢失报文，导致第四次挥手失败。如果没有等待时间，发送方在第四次挥手完毕之后，就关闭TCP连接，而此时接收方未收到该信息，故会一直打开TCP，并向发送方发送消息，但此时发送方已经无法接收消息。
一个MSL代表一个报文在传输过程中存在的最长时间，所以2MSL代表了往返的最长时间。如果服务器未收到第四次挥手，那么它会再次发送关闭请求，如果在2MSL中客户端未收到消息，这就表明服务器已经收到消息，并已关闭TCP连接。
1.5 SSL四次握手
- 明文：客户端请求建立SSL连接，并发送所支持的公钥加密方式，比如说RSA加密
- 明文：服务器选定加密方式，以及第三方机构颁布的证书，其中包括非对称加密的公钥
- 密文（以公钥加密）：验证其证书，是否合法，是否过期，如不合法则再次发送请求，否则将对称加密的密钥以公钥加密发送给服务器
- 服务器以其私钥解密对称加密的密钥。
1.6 说说HTTP和HTTPS的区别
- 端口号不同 HTTP是80，HTTPS 443
- HTTPS需要证书，证书来自第三方权威机构，一般需要支付高额费用
- HTTP是明文传输，不安全，HTTPS是密文传输
- 中间人攻击：直接截取报文，获取内容
- 完整性破坏：可以更改发送端的信息
- 对象身份存疑：无法验证对象的身份，如无法验证google的身份。
1.7 为什么要用对称加密内容
对称加密比较简单，消耗少
1.8 常见状态码
1.8.1 2XX系列：请求成功
- 200 ok，成功处理
- 204 只返回响应头
- 206 响应部分内容
1.8.2 3XX系列：重定向状态码
- 300 客户端请求了多个资源的URL，返回一个选项列表供客户选择
- 301 永久移除，Response包含一个 新的url，客户端跳转
- 302 暂时移除 ，Response包含一个 新的url供客户端跳转
- 304 客户的缓存资源是最新的，可以使用
1.8.3 4XX系列：客户端错误
- 400 错误请求
- 403 被服务器拒绝
- 404 未找到资源
- 405 不支持该请求方法
1.8.4 5XX系列：服务器错误
- 500 服务器内部错误
- 501 服务器不支持该请求方法
- 503（未提供此服务） 暂时无法提供服务，过段时间就可以
1.9 键入url的过程
总共分成两部分 ：
1.查询ip 2.建立连接
1.9.1 查询IP
- 先查看浏览器缓存中是否有该url的ip地址
- 查看OS中是否有该url的ip
- 发送DNS查询请求
- 目的ip本地DNS服务器的IP地址
- 如果不知道该服务器的MAC地址，就需要进行ARP查询，通过一个ARP查询广播，直到本地DNS服务器收到后发回一个应答，上面带着它的MAC地址
- 直到DNS服务器的MAC地址后就可以正式发送DNS查询请求了，基于UDP传输该查询报文
- 本地DNS服务器收到之后，如果能查询到就发回响应，如果不能就进行递归查询或者迭代查询，查到之后会发回结果
- 浏览器收到DNS响应报文
1.9.2 建立连接
此时已经知道目标地址的ip，所以可以开始建立TCP连接，进行三次握手
- 在第三次握手时可以发送数据到服务器，就发送GET请求
- 服务器接收到后会发出一个HTTP响应
- 然后客户端接收到之后会解析并渲染到页面上面
1.10 HTTP1.0 HTTP1.1 HTTP 2.0
1.10.1 HTTP1.1
- 增加了一些请求方法，比如HEAD，支持只响应 响应头
- 增加了虚拟主机功能，一台主机上可以支持多个虚拟主机，共享同一个IP
- 支持长连接，缓解了HTTP1.0 因每次请求都要进行TCP连接要造成的资源浪费
1.10.2 HTTP2.0
-
HTTP1.x支持文本解析协议，而HTTP2.0支持二进制解析协议，功能更强大
-
多路复用，可以同时发出多个request请求，并用request_id去区分，速度更快。
HTTP1.1也有类似的机制 pipelining ，但是默认是关闭的，由于传输是基于文本的，如果前一个内容阻塞，则后面的内容也会阻塞，而多路复用是基于二进制流的，所以不会有这个问题。
-
推送功能：将客户端未请求的，但之后很有可能会请求的资源也发送过去，这样也可以节省带宽和提高速度
-
请求头压缩：HTTP1.1的请求应答过程中，会一直带有重复的请求头，造成不必要的带宽浪费。HTTP2.0就让双方维护了一个请求头列表，这样就不用重复发送相同的内容了。
1.11 DNS解析（端口号53）
1.11.1 DNS解析过程 （递归查询和迭代查询）
- 递归查询
- 特点：
- 上一级的域名服务器帮助该级服务器去查询，并返回结果，不需要该级服务器再次去访问其他服务器
- 使用场景：
- 一般本地域名服务器查询是递归查询
- 特点：
- 迭代查询
- 特点：
- 上级域名服务器告知上上级服务器的IP地址给该级服务器，让该级服务器自己去访问查询
- 使用场景：
- 一般根域名服务器是迭代查询
- 特点：
1.11.2 DNS查询一定是基于UDP吗？
不一定
一般一个区中会有主域名服务器和辅助域名服务器，而主域名服务器给辅助域名服务器更新数据时会使用 TCP，而此时的数据是比较大的，UDP所承载的数据（512字节）小于TCP报文，且TCP安全。
1.12 RPC协议（远程调用协议）
1.13 Cookie和Session的区别
（1）共同点
- 因为HTTP是无状态协议，所以需要会话跟踪技术，而Cookie和Session就是常用的会话跟踪技术。
- 两个都有有效时间
（2）区别
- Cookie存在客户端，Session存在服务器
- cookie不安全，session比较安全
- 性能不同，当访问增多session会比较占用服务器性能。
- 存储数据大小不同：cookie 4k，session没有明确限制
1.14 断点传输
在下载过程中都是多线程一部分一部分下载，可能中途出故障停顿了，则后面可以支持继续下载
实现原理
- 客户端向服务器发送一个下载请求，服务器返回一个响应，且里面有一个响应头
- Content-Length表示文件的长度
- 客户端再发送 GET /test.zip HTTP/1.0User-Agent: NetFox RANGE: bytes=44445555-
- 表示从44445555字节开始传送
- 服务器发回206Content-Length=66667777Content-Range=bytes 44445555-66667777Content-Type=application/octet-stream
- 表示发送了44445555-66667777字节的数据
- 但是还有一个问题，就是终端发起请求时，服务端的数据内容已经发生变化，则需要两个头部字段识别
- ETag，当作文件的唯一标识，比如说MD5值
- Last-Modified，最后的修改时间
2.运输层
2.1TCP
2.1.1 介绍一下TCP
TCP是一个在运输层的可靠传输协议。
（1）它的可靠性基于：
- 三次握手
- 流量控制
- 拥塞控制
- 重传机制
（2）优缺点（对于UDP）
- 可靠性（看重信息完整度的应用，如HTTP）
- 速度慢
- 首部开销大
2.1.2TCP的拥塞控制
(1)拥塞控制的原因
- 传输速度过快，导致路径上的路由器缓存过载，以至于丢包，然后丢包后，又需重新发送数据。
（2）拥塞控制方法
- 端到端（常用的处理方法，接收方通过对网络行为的观察）
- 网络辅助的方法
- l路由器直接告知发送方阻塞
- 路由器在发送给接收端的报文中添加信息，表示拥塞，然后发送方告知发送方。
（3）TCP拥塞控制
- 接收端如何感知拥塞？
- 数据包接收超时
- 三个冗余ACK
- 接收端如何限制发送端的发送速率
- 以何种算法改变发送速率
三个阶段(在默认接收方window无限大，发送方缓存限制的条件下)
-
慢启动
-
起步速度为1MSS（最大报文传输）
-
每接收一个ACK，增加1MSS，所以每个RTT（往返时延），乘2
-
超时则返回慢启动，并设立门槛值
-
三个冗余ACK，则进入快速恢复
-
-
拥塞避免
- 速率到了门槛值之后，变成一个RTT增加时一个MSS，如果超时，则进入慢启动
- 如果3个冗余ACK则进入快速回复
-
快速恢复
- 每个冗余ACK，速率+1MSS，直到正确的ACK抵达，进入拥塞避免 ，门槛值和速率都变为一半， 如果遇到超时情况则进入慢启动状态。
2.1.3 流量控制
（1）原因
发送方发送过快，导致接收方缓存溢出，以至于丢包的情况。
（2）处理
接收方维护一个接收窗口cwnd，在发送数据的时候，告知发送方cwnd的大小，发送方根据cwnd的大小调整发送速率。
如果接收方缓存已满
cwnd = 0，且发送方收到后，发送方之后每次发送只有一个字节数据的报文段。
2.1.4 快速重传和超时重传
（1） 快速重传
收到三次冗余ACK时，经过接收方的三次提醒，重传
-
为什么是三次冗余ACK
因为冗余ACK有可能是乱序，引起的，而2次冗余ACK的话，乱序的可能性还是比较大的，3次的话还可以
（2）超时重传
超过时间没有收到应答，发送方猜测 发生丢包事件，重传
2.1.5 TCP高性能保证 （三个人每人50M ，总带宽为100M 如何实现）
-
滑动窗口缓存机制
发送方可以发送 发送窗口内的所有数据，而不需要一个一个发送，接收方可以接收 接收窗口的所有数据
-
快速重传机制
如果收到三次冗余ACK会重传
-
流量控制
通过通知发送方 接收方的缓存剩余空间，控制发送方的发送速率，以免造成不必要的丢包
2.1.6 为什么多TCP连接比单TCP连接要快
- 因为TCP的拥塞控制，在两个TCP使用同一链路时，会均分带宽，而不同时用时，可以获得全部带宽。
2.1.7 客户端最多可以建立多少个tcp连接
- tcp连接的端口号 是利用空闲的端口号，故可以用65525-1024（预留端口）
2.1.8 服务器最多可以建立多少个tcp连接
tcp的标识是（源IP，源端口号，目的IP，目的端口号）
对于服务器只有 服务器ip和服务器端口号可变
所以 客户ip*客户端口数
2.1.9 为什么TCP会造成粘包问题？如何处理
（1）为什么UDP不会产生粘包问题？
- UDP是面向数据报的，UDP是无连接的，是一对多的模式，故接收端的缓冲区采用链式结构记录每个UDP包，而每个UDP包里面都有长度等信息
（2）为什么TCP会粘包
- 发送方：TCP为了提高效率会把多个间隔小的长度短的数据报合成为一个大的数据报
- 接收方：接收者不及时接收数据，堆积于缓存中。
（3）什么时候不需要处理粘包
- 无结构数据，如文件流
- 每次只发送一段数据就关闭连接（因为只有一种结构
（4）如果处理粘包
- 发送方和接收方
- 发送方强制每次不优化直接发送数据包（效率低）
- 接收方提高接收的优先级（并不能避免粘包）
- 数据包结构
- 发定长的数据包
- 数据包写明长度
- 特殊标记分隔
2.1.10 为什么TCP的序列号是随机的
安全问题，黑客可以很容易得到你的初始化序列号。
2.1.11 一个TCP数据包有多大，UDP呢
-
局域网链路 最大可传输单元 MTU = 1500Byte （以太网链路）
-
TCP 一般最大可传输单元 MMU =1500Byte -20IP包头-20TCP包头=1460
-
UDP = 1500 - 20（IP头） -8TCP包头=1472
-
Internet 下MTU = 576 Byte
2.1.11多个程序可以绑定同一个端口吗
可以 ，端口复用技术。
OS如何区分一个socket？
五元组
2.2UDP
2.2.1介绍一下UDP
UDP是一个在运输层的不可靠协议
（1）优缺点
- 首部开销小
- 无连接，速度块
- 不可靠
（2）如何以UDP实现可靠传输？
- 序列号确认机制
- 重传机制
（3）DNS为什么要用UDP
- 访问冷门网站时，可能会多次迭代查询，如果每次都要进行三次握手会浪费时间。
- DNS发送的数据量比较小。
- DNS有时也会使用TCP，比如解析到的IP太多了，一个相应的UDP放不下。一般本地DNS服务会有主辅之分，相互通信时，就会用到TCP。
3.网络层
3.1 为什么IPv4还没有耗尽
网络地址转换，比如说一个家庭的内部设备所用的都是同一个IP。基于DHCP服务器。
3.2 IP包经过路由器会发生什么
- 解析IP，然后确定往哪一个接口转发出去，但是目的IP和源IP并不会改
- 更改的只有MAC地址
4.七层OSI模型
- 应用层：HTTP,FTP,DNS,DHCP
- 表示层
- 会话层
- 运输层: TCP UDP
- 网络层 IP ARP
- 链路层
- 物理层
