TCP/IP协议分层
应用层
- TFP
- DNS
DNS域名解析的过程
在浏览器DNS缓存中搜索
读取系统的hosts文件，查找其中是否有对应的ip
向本地配置的首选DNS服务器发起域名解析请求
- HTTP
传输层
TCP(Transmission Control Protocel，传输控制协议)
1、建立连接三次握手
- 发送端首先发送一个带SYN（synchronize/'sɪŋkrənaɪz/同步 星课耐子）标志的数据包给接收方
- 接收方收到后，回传一个带有SYN/ACK(acknowledegment/ək'nɑlɪdʒmənt/确认回单)标志的数据包以示传达确认信息
- 最后发送方再回传一个带ACK标志的数据包，代表握手结束
- 在这过程中若出现问题中断，TCP会再次发送相同的数据包。建立之后开始数据通信。
问题1: 为什么不能是二次
三次握手不是TCP本身的要求, 而是为了满足"在不可靠信道上可靠地传输信息"这一需求所导致的，三次通信是理论上的最小值。为了防止已失效的连接请求报文段突然又传送到了服务端，因而产生错误，失效的连接请求：若客户端向服务端发送的连接请求丢失，客户端等待应答超时后就会再次发送连接请求，此时，上一个连接请求就是『失效的』，如果那个失效的连接请求抵达了服务端，由于只有两次握手，服务端收到请求就会进入接收状态，等待发送数据或主动发送数据。但此时的客户端早已进入CLOSED状态，服务端将会一直等待下去，这样浪费服务端连接资源。三次就可以四次就浪费了资源。
2、断开的四次挥手
- 客户端A发送一个FIN，用来关闭客户A到服务器B的数据传送
- 服务器B收到这个FIN，它发回一个ACK
- 服务器B关闭与客户端A的连接，发送一个FIN给客户端A
- 客户端A发回ACK报文确认
问题1: 为什么挥手需要四次
关闭连接时，当收到对方的FIN报文通知时，它仅仅表示对方没有数据发送给你了；但未必你所有的数据都全部发送给对方了，所以你可能未必会马上会关闭连接,也即你可能还需要发送一些数据给对方之后，再发送FIN报文给对方来表示你同意现在可以关闭连接了，所以它这里的ACK报文和FIN报文多数情况下都是分开发送的。
问题2:四次挥手释放连接时，等待2MSL的意义
为了保证A发送的最有一个ACK报文段能够到达B。这个ACK报文段有可能丢失，因而使处在LAST-ACK状态的B收不到对已发送的FIN和ACK 报文段的确认。B会超时重传这个FIN和ACK报文段，而A就能在2MSL时间内收到这个重传的ACK+FIN报文段。接着A重传一次确认
UDP(用户数据协议)
问题1：TCP协议和UDP协议的区别是什么？
- TCP协议是有连接的，有连接的意思是开始传输实际数据之前TCP的客户端和服务器端必须通过三次握手建立连接，会话结束之后也要结束连接。而UDP是无连接的
- TCP协议保证数据按序发送，按序到达，提供超时重传来保证可靠性，但是UDP不保证按序到达，甚至不保证到达，只是努力交付，即便是按序发送的序列，也不保证按序送到。
- TCP协议所需资源多，TCP首部需20个字节（不算可选项），UDP首部字段只需8个字节。
- TCP有流量控制和拥塞控制，UDP没有，网络拥堵不会影响发送端的发送速率
- TCP是一对一的连接，而UDP则可以支持一对一，多对多，一对多的通信。
- TCP面向的是字节流的服务，UDP面向的是报文的服务。
网络层
在众多链路中，找到一条合适的传输路线，就是Ip
链路层
硬件上的范畴均在链路层上
发起HTTP请求
请求方法
- TRACE:追踪路径
- OPTIONS:询问支持的方法
- DELETE:删除
- HEAD:获取报文首部
- PUT:增
- POST:传输实体主体（改）
- GET:获取资源（查）
问题1：get和post方法有什么区别
- GET在浏览器回退时是无害的，而POST会再次提交请求。
- GET产生的URL地址可以被Bookmark，而POST不可以。
- GET请求会被浏览器主动cache，而POST不会，除非手动设置。
- GET请求只能进行url编码，而POST支持多种编码方式。
- GET请求参数会被完整保留在浏览器历史记录里，而POST中的参数不会被保留。
- GET请求在URL中传送的参数是有长度限制的，而POST么有。
- 对参数的数据类型，GET只接受ASCII字符，而POST没有限制。
- GET比POST更不安全，因为参数直接暴露在URL上，所以不能用来传递敏感信息。
- GET参数通过URL传递，POST放在Request body中
- 本质的区别:GET产生一个TCP数据包；POST产生两个TCP数据包
对于GET方式的请求，浏览器会把http header和data一并发送出去，
服务器响应200（返回数据）；
而对于POST，浏览器先发送header，服务器响应100 continue，
浏览器再发送data，服务器响应200 ok（返回数据）
问题2：get为什么有长度限制？
- HTTP 协议 未规定 GET 和POST的长度限制
- GET的最大长度显示是因为 浏览器和 web服务器限制了 URI的长度
- 不同的浏览器和WEB服务器，限制的最大长度不一样
- 要支持IE，则最大长度为2083byte，若只支持Chrome，则最大长度 8182byte
状态码
1**：信息性状态码
2**：成功状态码
200：OK 请求正常处理
204：No Content请求处理成功，但没有资源可返回 form提交，之后不跳转
206：Partial Content对资源的某一部分的请求 文件大，分段请求的情况
3**：重定向状态码
301：Moved Permanently 永久重定向 从响应头的location中取重定向地址
302：Found 临时性重定向
303：与302状态码有相似功能，只是它希望客户端在请求一个URI的时候，
能通过GET方法重定向到另一个URI上
304：Not Modified 缓存中读取
307：临时重定向，与302类似，只是强制要求使用POST方法
4**：客户端错误状态码
400：Bad Request 请求报文中存在语法错误
401：Unauthorized需要有通过Http认证的认证信息
403：Forbidden访问被拒绝
404：Not Found无法找到请求资源
5**：服务器错误状态码
500：Internal Server Error 服务器端在执行时发生错误
502：对用户访问请求的响应超时造成的
503：Service Unavailable 服务器处于超负载或者正在进行停机维护
HTTP请求报文与响应报文格式
请求报文包含四部分：
- a、请求行：包含请求方法、URI、HTTP版本信息
- b、请求首部字段
- c、请求内容实体
- d、一个空行
响应报文包含四部分:
- a、状态行：包含HTTP版本、状态码、状态码的原因短语
- d、一个空行
- c、响应内容实体
- b、响应首部字段
请求头
5A 5C D H 5I 2R U 20
| Header | 解释 | 示例 |
|---|---|---|
| Accept | 指定客户端能够接收的内容类型 | Accept: text/plain, text/html,application/json |
| Accept-Charset | 浏览器可以接受的字符编码集。 | Accept-Charset: iso-8859-5 |
| Accept-Encoding | 指定浏览器可以支持的web服务器返回内容压缩编码类型。 | Accept-Encoding: compress, gzip |
| Accept-Language | 浏览器可接受的语言 | Accept-Language: en,zh |
| Accept-Ranges | 可以请求网页实体的一个或者多个子范围字段 | Accept-Ranges: bytes |
| Cache-Control | 指定请求和响应遵循的缓存机制 | Cache-Control: no-cache |
| Connection | 表示是否需要持久连接。（HTTP 1.1默认进行持久连接） | Connection: close |
| Cookie | HTTP请求发送时，会把保存在该请求域名下的所有cookie值一起发送给web服务器。 | Cookie: $Version=1; Skin=new; |
| Content-Length | 请求的内容长度 | Content-Length: 348 |
| Content-Type | 请求的与实体对应的MIME信息 | Content-Type: application/x-www-form-urlencoded |
| Date | 请求发送的日期和时间 | Date: Tue, 15 Nov 2010 08:12:31 GMT |
| Host | 指定请求的服务器的域名和端口号 | Host: www.zcmhi.com |
| If-Match | 只有请求内容与实体相匹配才有效 | If-Match: “737060cd8c284d8af7ad3082f209582d” |
| If-Modified-Since | 如果请求的部分在指定时间之后被修改则请求成功，未被修改则返回304代码 | If-Modified-Since: Sat, 29 Oct 2010 19:43:31 GMT |
| If-None-Match | 如果内容未改变返回304代码，参数为服务器先前发送的Etag，与服务器回应的Etag比较判断是否改变 | If-None-Match: “737060cd8c284d8af7ad3082f209582d” |
| If-Range | 如果实体未改变，服务器发送客户端丢失的部分，否则发送整个实体。参数也为Etag | If-Range: “737060cd8c284d8af7ad3082f209582d” |
| If-Unmodified-Since | 只在实体在指定时间之后未被修改才请求成功 | If-Unmodified-Since: Sat, 29 Oct 2010 19:43:31 GMT |
| Range | 只请求实体的一部分，指定范围 | Range: bytes=500-999 |
| Referer | 先前网页的地址，当前请求网页紧随其后,即来路 | Referer: www.zcmhi.com/archives... |
| User-Agent | User-Agent的内容包含发出请求的用户信息 | User-Agent: Mozilla/5.0 (Linux; X11) |
响应头
3A 7C date 2 (E L S) 17
| Header | 解释 | 示例 |
|---|---|---|
| Accept-Ranges | 表明服务器是否支持指定范围请求及哪种类型的分段请求 | Accept-Ranges: bytes |
| Age | 从原始服务器到代理缓存形成的估算时间（以秒计，非负） | Age: 12 |
| Allow | 对某网络资源的有效的请求行为，不允许则返回405 | Allow: GET, HEAD |
| Cache-Control | 告诉所有的缓存机制是否可以缓存及哪种类型 | Cache-Control: no-cache |
| Content-Encoding | web服务器支持的返回内容压缩编码类型。 | Content-Encoding: gzip |
| Content-Language | 响应体的语言 | Content-Language: en,zh |
| Content-Length | 响应体的长度 | Content-Length: 348 |
| Content-Location | 请求资源可替代的备用的另一地址 | Content-Location: /index.htm |
| Content-Range | 在整个返回体中本部分的字节位置 | Content-Range: bytes 21010-47021/47022 |
| Content-Type | 返回内容的MIME类型 | Content-Type: text/html; charset=utf-8 |
| Date | 原始服务器消息发出的时间 | Date: Tue, 15 Nov 2010 08:12:31 GMT |
| ETag | 请求变量的实体标签的当前值 | ETag: “737060cd8c284d8af7ad3082f209582d” |
| Expires | 响应过期的日期和时间 | Expires: Thu, 01 Dec 2010 16:00:00 GMT |
| Last-Modified | 请求资源的最后修改时间 | Last-Modified: Tue, 15 Nov 2010 12:45:26 GMT |
| Location | 用来重定向接收方到非请求URL的位置来完成请求或标识新的资源 | Location: www.zcmhi.com/archives... |
| Server | web服务器软件名称 | Server: Apache/1.3.27 (Unix) (Red-Hat/Linux) |
| Set-Cookie | 设置Http Cookie | Set-Cookie: UserID=JohnDoe; Max-Age=3600; Version=1 |
URL、URN、URI
- URL和URN都是URI的子集
- URL类似于住址，它告诉你一种寻找目标的方式
- 一个人的名字看作是URN；因此可以用URN来唯一标识一个实体
HTTPS
https其实就是在HTTP跟TCP中间加多了一层加密层TLS/SSL。
神马是TLS/SSL？
通俗的讲，TLS、SSL其实是类似的东西，SSL是个加密套件，负责对HTTP的数据进行加密。TLS是SSL的升级版。现在提到HTTPS，加密套件基本指的是TLS。
传输加密的流程
原先是应用层将数据直接给到TCP进行传输，现在改成应用层将数据给到TLS/SSL，将数据加密后，再给到TCP进行传输。
HTTPS是如何加密数据的
非对称加密 与 对称密钥 结合 利用非对称加密来传输对称密钥
公钥如何获取
CA（证书颁发机构）网站向CA提交了申请，CA审核通过后，将证书颁发给网站，用户访问网站的时候，网站将证书给到用户
数据传输仅单向安全
HTTPS虽然用到了公开密钥加密，但同时也结合了其他手段，如对称加密，来确保授权、加密传输的效率、安全性。
概括来说，整个简化的加密通信的流程就是：
小明访问XX，XX将自己的证书给到小明（其实是给到浏览器，小明不会有感知）
浏览器从证书中拿到XX的公钥A
浏览器生成一个只有自己自己的对称密钥B，用公钥A加密，并传给XX（其实是有协商的过程，这里为了便于理解先简化）
XX通过私钥解密，拿到对称密钥B
浏览器、XX 之后的数据通信，都用密钥B进行加密
注意：对于每个访问XX的用户，生成的对称密钥B理论上来说都是不一样的。比如小明、小王、小光，可能生成的就是B1、B2、B3
证书的安全性怎么保证
数字签名、摘要是证书防伪非常关键的武器
HTTPS握手流程
- 网站是怎么把证书给到用户（浏览器）的
- 上面提到的对称密钥是怎么协商出来的
上面两个问题，其实就是HTTPS握手阶段要干的事情。HTTPS的数据传输流程整体上跟HTTP是类似的，同样包含两个阶段：
握手、数据传输。
握手：证书下发，密钥协商（这个阶段都是明文的）
数据传输：这个阶段才是加密的，用的就是握手阶段协商出来的对称密钥
http2
二进制协议
多路复用
HPACK 头部压缩
服务器推送