http的一些知识

TCP/IP协议分层

应用层

• TFP
• DNS

---

DNS域名解析的过程
在浏览器DNS缓存中搜索		
读取系统的hosts文件，查找其中是否有对应的ip
向本地配置的首选DNS服务器发起域名解析请求

---

• HTTP

传输层

TCP(Transmission Control Protocel，传输控制协议)

1、建立连接三次握手

1. 发送端首先发送一个带SYN（synchronize/'sɪŋkrənaɪz/同步 星课耐子）标志的数据包给接收方
2. 接收方收到后，回传一个带有SYN/ACK(acknowledegment/ək'nɑlɪdʒmənt/确认回单)标志的数据包以示传达确认信息
3. 最后发送方再回传一个带ACK标志的数据包，代表握手结束
4. 在这过程中若出现问题中断，TCP会再次发送相同的数据包。建立之后开始数据通信。

问题1: 为什么不能是二次

三次握手不是TCP本身的要求, 而是为了满足"在不可靠信道上可靠地传输信息"这一需求所导致的，三次通信是理论上的最小值。为了防止已失效的连接请求报文段突然又传送到了服务端，因而产生错误，失效的连接请求：若客户端向服务端发送的连接请求丢失，客户端等待应答超时后就会再次发送连接请求，此时，上一个连接请求就是『失效的』，如果那个失效的连接请求抵达了服务端，由于只有两次握手，服务端收到请求就会进入接收状态，等待发送数据或主动发送数据。但此时的客户端早已进入CLOSED状态，服务端将会一直等待下去，这样浪费服务端连接资源。三次就可以四次就浪费了资源。

2、断开的四次挥手

1. 客户端A发送一个FIN，用来关闭客户A到服务器B的数据传送
2. 服务器B收到这个FIN，它发回一个ACK
3. 服务器B关闭与客户端A的连接，发送一个FIN给客户端A
4. 客户端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协议的区别是什么？

1. TCP协议是有连接的，有连接的意思是开始传输实际数据之前TCP的客户端和服务器端必须通过三次握手建立连接，会话结束之后也要结束连接。而UDP是无连接的
2. TCP协议保证数据按序发送，按序到达，提供超时重传来保证可靠性，但是UDP不保证按序到达，甚至不保证到达，只是努力交付，即便是按序发送的序列，也不保证按序送到。
3. TCP协议所需资源多，TCP首部需20个字节（不算可选项），UDP首部字段只需8个字节。
4. TCP有流量控制和拥塞控制，UDP没有，网络拥堵不会影响发送端的发送速率
5. TCP是一对一的连接，而UDP则可以支持一对一，多对多，一对多的通信。
6. TCP面向的是字节流的服务，UDP面向的是报文的服务。

网络层

在众多链路中，找到一条合适的传输路线，就是Ip

链路层

硬件上的范畴均在链路层上

发起HTTP请求

请求方法

1. TRACE:追踪路径
2. OPTIONS:询问支持的方法
3. DELETE:删除
4. HEAD:获取报文首部
5. PUT:增
6. POST:传输实体主体（改）
7. GET:获取资源（查）

问题1：get和post方法有什么区别

1. GET在浏览器回退时是无害的，而POST会再次提交请求。
2. GET产生的URL地址可以被Bookmark，而POST不可以。
3. GET请求会被浏览器主动cache，而POST不会，除非手动设置。
4. GET请求只能进行url编码，而POST支持多种编码方式。
5. GET请求参数会被完整保留在浏览器历史记录里，而POST中的参数不会被保留。
6. GET请求在URL中传送的参数是有长度限制的，而POST么有。
7. 对参数的数据类型，GET只接受ASCII字符，而POST没有限制。
8. GET比POST更不安全，因为参数直接暴露在URL上，所以不能用来传递敏感信息。
9. GET参数通过URL传递，POST放在Request body中
10. 本质的区别:GET产生一个TCP数据包；POST产生两个TCP数据包
    对于GET方式的请求，浏览器会把http header和data一并发送出去，
    服务器响应200（返回数据）；
    而对于POST，浏览器先发送header，服务器响应100 continue，
    浏览器再发送data，服务器响应200 ok（返回数据）

问题2：get为什么有长度限制？

1. HTTP 协议 未规定 GET 和POST的长度限制
2. GET的最大长度显示是因为 浏览器和 web服务器限制了 URI的长度
3. 不同的浏览器和WEB服务器，限制的最大长度不一样
4. 要支持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

1. URL和URN都是URI的子集
2. URL类似于住址，它告诉你一种寻找目标的方式
3. 一个人的名字看作是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 头部压缩

服务器推送