1.http状态码
400 Bad Request 请求出现语法错误。
401 Unauthorized 客户试图未经授权访问受密码保护的页面。应答中会包含一个WWW-Authenticate头，浏览器据此显示用户名字/密码对话框，然后在填写合适的Authorization头后再次发出请求。
403 Forbidden 资源不可用。服务器理解客户的请求，但拒绝处理它。通常由于服务器上文件或目录的权限设置导致。
404 Not Found 无法找到指定位置的资源。这也是一个常用的应答。
405 Method Not Allowed 请求方法（GET、POST、HEAD、DELETE、PUT、TRACE等）对指定的资源不适用。（HTTP 1.1新）
406 Not Acceptable 指定的资源已经找到，但它的MIME类型和客户在Accpet头中所指定的不兼容（HTTP 1.1新）。
407 Proxy Authentication Required 类似于401，表示客户必须先经过代理服务器的授权。（HTTP 1.1新）
502 Bad Gateway 服务器作为网关或者代理时，为了完成请求访问下一个服务器，但该服务器返回了非法的应答。
503 Service Unavailable 服务器由于维护或者负载过重未能应答。例如，Servlet可能在数据库连接池已满的情况下返回503。服务器返回503时可以提供一个Retry-After头。
504 Gateway Timeout 由作为代理或网关的服务器使用，表示不能及时地从远程服务器获得应答。（HTTP 1.1新）
2.http请求的几种方法
- get
- post
创建资源，因此不是幂等的 - put
更新资源，资源本身不变，因此是幂等的 - head
获取首部 - delete
- options
- patch
3.http版本
- http1.0
- 短连接
2 http1.1 - Connection为keep-Alive和Close对应长连接和短连接
- 发送方不用等上一次的响应就可以发送下一次请求
- 支持断点续传
- 增加了一些header（与缓存控制、）
- Delete Options的添加
3 http2.0 - 二进制分帧
不同数据流的帧可以交错发送。
同个域名只需要占用一个 TCP 连接，消除了因多个 TCP 连接而带来的延时和内存消耗。
单个连接上可以并行交错的请求和响应，之间互不干扰。 - 服务端推送
请求index.html时，会自动请求里面包含的js img等资源 - 首部压缩
和之前的header相同则不需要重复发送
4.tcp滑动窗口
- 接收方根据自己接收缓存的大小，告诉发送方窗口的大小设置为多少它才来得及接受。
-
发送方窗口为min(拥塞窗口，接收方告诉的窗口)
image.png
5.tcp三次握手
客户端发送的一个请求由于在中间节点延时，以致于等到连接释放后再重新到达服务端。那么如果采用两次握手，只需要server端发送确认就认为建立了连接。这样建立连接后客户端不理睬服务端的确认，导致server一直重发，进而浪费服务端资源，而采用三次握手就可以解决。
6.tcp四次挥手
7.tcp最后一次要多等一段时间
最后一次报文可能丢失，如果server端没有收到最后一次报文，会不断重发第三次的报文，因此客户端不能立刻关闭。从最后一次报文发送到server重新发第三次的报文总共是2MSL(两个报文最长存活时间，因此要等2MSL)
8.tcp的拥塞控制
对网络带宽需求的总和 > 可用资源
方式一：
方式二：收到三个冗余ack执行快重传和快恢复
9.tcp和udp
- tcp面向连接，保证可靠传输，udp无连接，不可靠
- tcp慢，udp快
10.OSI七层
1.应用层
- DNS（53） HTTP（80） SMTP（25）
- 定义应用进程之间通信的规则
2.运输层
- 提供端到端的服务（进程到进程）
3.网络层
- 分组传输 路由
4.数据链路层
- 比特流封装 点到点 物理寻址
5.物理层
- 物理设备的标准 电气特性（高电平代表什么含义）
11.输入url的过程
12.DNS过程
总共13个根域名服务器
缓存：
浏览器缓存 系统缓存 路由器缓存 ISP服务器缓存 根域名服务器缓存 顶级域名服务器缓存 二级域名服务器缓存
13.点到点和端到端
- 端到端强调发送方和接收方建立一条逻辑链路，不知道中间点的存在。点到点枪强调把数据传给直接相连的设备，再传到另一台。
- 端到端需要发送方始终参与，点对点不需要
- 端对端建立连接后，发送端知道接收端一定能收到，而点对点的发送端不知道接收端能不能收到。
14.tcp如何保证可靠传输
- 确认
- 超时重传
- 校验和
- 流量控制
- 拥塞控制
- 序列号
15.tcp序列号的作用
接收端通过序列号确认前面的字节都收到了。使用随机的序列号的作用参考这里
16.https过程
client向server发送请求https://baidu.com，然后连接到server的443端口，发送的信息主要是随机值和客户端支持的加密算法。
server接收到信息之后给予client响应握手信息，包括随机值2和匹配好的协商加密算法，这个加密算法一定是client发送给server加密算法的子集。
随即server给client发送第二个响应报文是数字证书。证书包含了服务端的公钥和CA的签名（对证书的其他内容先摘要，再用CA私钥加密）和域名，公司等信息。
客户端解析证书，一方面通过浏览器内置的CA公钥将签名解密，另一方面，对证书的内容使用同样的摘要算法求哈希值，对比如果相等，则 生成一个随即值（预主秘钥）。
客户端使用服务端公钥加密随机值传给服务端
客户端和服务端根据三个共享的随机数生成会话密钥
客户端通过会话秘钥加密客户端发一个「Change Cipher Spec」，告诉服务端开始使用加密方式发送消息。再发一个「Encrypted Handshake Message（Finishd）」消息，把之前所有发送的数据做个摘要，再用会话密钥（master secret）加密一下，让服务器做个验证，验证加密通信是否可用和之前握手信息是否有被中途篡改过。
同样服务端和第7步一样
17.tcp粘包问题
为了传输更快，将多个数据包封装成一个大的数据包，导致接收方难以分辨出完整的数据包。
图示：
解决：
- 发送方和接收方都以固定长度发送和接收
- 发送数据包的尾部添加标记序列
- 定义一个包头，包头里面说明下次要接收多少字节的数据
