报文

请求报文
由请求行（请求方法、请求 URI、协议版本），首部字段和内容实体构成的。

接收到请求的服务器，会将请求内容的处理结果以响应的形式返回。响应报文基本上由协议版本、状态码（表示请求成功或失败的数字代码）、用以解释状态码的原因短语、可选的响应首部字段以及实体主体构成。

相应报文
由状态行（状态码，状态码标识语，协议版本），首部字段和内容实体构成。

报文结构

HTTP 报文大致可分为报文首部和报文主体两块。两者由最初出现的空行（CR+LF）来划分。通常，并不一定要有报文主体。

首部字段
Content-Type: text/html 首部字段名为 Content-Type，字符串 text/html 是字段值

Keep-Alive: timeout=15, max=100 当 HTTP 报文首部中出现了两个或两个以上具有相同首部字段名时会怎么样？这种情况在规范内尚未明确，根据浏览器内部处理逻辑的不同，结果可能并不一致。有些浏览器会优先处理第一次出现的首部字段，而有些则会优先处理最后出现的首部字段。

请求方法

GET ：获取资源 POST：传输实体主体虽然用 GET 方法也可以传输实体的主体，但一般不用 GET 方法进行传输，而是用 POST 方法。虽说 POST 的功能与 GET很相似，但POST 的主要目的并不是获取响应的主体内容。 PUT：传输文件

HEAD：获得报文首部 HEAD 方法和 GET 方法一样，只是不返回报文主体部分。用于确认URI 的有效性及资源更新的日期时间等。

DELETE：删除文件 OPTIONS：询问支持的方法 TRACE：追踪路径

关于HTTP请求GET和POST的区别

1.数据放置的位置： GET提交，请求的数据会附在URL之后（就是把数据放置在HTTP协议头＜request-line＞中），以?分割URL和传输数据，多个参数用&连接;例如：login.action?name=hyddd&password=idontknow&verify=%E4%BD%A0%E5%A5%BD。如果数据是英文字母/数字，原样发送，如果是空格，转换为+，如果是中文/其他字符，则直接把字符串用BASE64加密，得出如：%E4%BD%A0%E5%A5%BD，其中％XX中的XX为该符号以16进制表示的ASCII。

POST提交：把提交的数据放置在是HTTP包的包体＜request-body＞中。上文示例中红色字体标明的就是实际的传输数据

因此，GET提交的数据会在地址栏中显示出来，而POST提交，地址栏不会改变

2.传输数据的大小：

首先声明,HTTP协议没有对传输的数据大小进行限制，HTTP协议规范也没有对URL长度进行限制。而在实际开发中存在的限制主要有：

GET:特定浏览器和服务器对URL长度有限制，例如IE对URL长度的限制是2083字节(2K+35)。对于其他浏览器，如Netscape、FireFox等，理论上没有长度限制，其限制取决于操作系统的支持。

因此对于GET提交时，传输数据就会受到URL长度的限制。

POST:由于不是通过URL传值，理论上数据不受限。但实际各个WEB服务器会规定对post提交数据大小进行限制，Apache、IIS6都有各自的配置。

3.安全性：

POST的安全性要比GET的安全性高。注意：这里所说的安全性和上面GET提到的“安全”不是同个概念。上面“安全”的含义仅仅是不作数据修改，而这里安全的含义是真正的Security的含义，比如：通过GET提交数据，用户名和密码将明文出现在URL上，因为 (1)登录页面有可能被浏览器缓存， (2)其他人查看浏览器的历史纪录，那么别人就可以拿到你的账号和密码了。

get请求的head和body是怎么区分呢

其实不管get还是post，考察的还是http协议。http请求是由请求行，首部，实体三个部分组成。请求行包含方法，url，版本，遇到/r/n结束。接下来就是首部，这里放header的key和value。两个/r/n结束。最后就是实体。顺便提一句，Http响应是由状态行，首部，实体三部分组成。状态行有版本，状态码，短语组成，别搞混了

握手和挥手

三次握手（建立连接）你能听到吗？我能听到，你能听到吗？我能听到，bilibili

四次挥手（断开连接）我可以挂掉吗好，你可以挂掉挂了挂了

Cookie

cookie的存在是为了让服务端和客服端（持久的）相互认识。由服务器生成，客户端保存。

Cookie 会根据从服务器端发送的响应报文内的一个叫做 Set-Cookie 的首部字段信息，通知客户端保存 Cookie。当下次客户端再往该服务器发送请求时，客户端会自动在请求报文中加入 Cookie 值后发送出去。服务器端发现客户端发送过来的 Cookie后，会去检查究竟是从哪一个客户端发来的连接请求，然后对比服务器上的记录，最后得到之前的状态信息。

状态码

类别	原因短语
1XX	Informational（信息性状态码）接收的请求正在处理
2XX	Success（成功状态码）请求正常处理完毕
3XX	Redirection（重定向状态码）需要进行附加操作以完成请求
4XX	Client Error（客户端错误状态码）服务器无法处理请求
5XX	Server Error（服务器错误状态码）服务器处理请求出错

HTTPS

HTTP + 加密 + 认证 + 完整性保护 =HTTPS

HTTPS 是身披 SSL 外壳的 HTTP

HTTPS 并非是应用层的一种新协议。只是 HTTP 通信接口部分用SSL（Secure Socket Layer）和 TLS（Transport Layer Security）协议代替而已。

通常，HTTP 直接和 TCP 通信。当使用 SSL时，则演变成先和 SSL通信，再由 SSL和 TCP 通信了。简言之，所谓 HTTPS，其实就是身披SSL协议这层外壳的 HTTP。

http和https的区别

http缺点：
1，数据是明文
2，不验证身份
3，不验证报文的完整性
4，http(80),https(443)

https 完善了http的不足，因为完善了不足，所以效率会变慢。http握手是3次，htts是8次。

公开密钥加密

公开密钥加密使用一对非对称的密钥。一把叫做私有密钥（private key），另一把叫做公开密钥（public key）。顾名思义，私有密钥不能让其他任何人知道，而公开密钥则可以随意发布，任何人都可以获得。

使用公开密钥加密方式，发送密文的一方使用对方的公开密钥进行加密处理，对方收到被加密的信息后，再使用自己的私有密钥进行解密。利用这种方式，不需要发送用来解密的私有密钥，也不必担心密钥被攻击者窃听而盗走。

另外，要想根据密文和公开密钥，恢复到信息原文是异常困难的，因为解密过程就是在对离散对数进行求值，这并非轻而易举就能办到。退一步讲，如果能对一个非常大的整数做到快速地因式分解，那么密码pojie还是存在希望的。但就目前的技术来看是不太现实的。

证明公开密钥正确性的证书

公开密钥加密方式还是存在一些问题的。那就是无法证明公开密钥本身就是货真价实的公开密钥。比如，正准备和某台服务器建立公开密钥加密方式下的通信时，如何证明收到的公开密钥就是原本预想的那台服务器发行的公开密钥。或许在公开密钥传输途中，真正的公开密钥已经被攻击者替换掉了。

首先，服务器的运营人员向数字证书认证机构提出公开密钥的申请。数字证书认证机构在判明提出申请者的身份之后，会对已申请的公开密钥做数字签名，然后分配这个已签名的公开密钥，并将该公开密钥放入公钥证书后绑定在一起。

服务器会将这份由数字证书认证机构颁发的公钥证书发送给客户端，以进行公开密钥加密方式通信。公钥证书也可叫做数字证书或直接称为证书。

接到证书的客户端可使用数字证书认证机构的公开密钥，对那张证书上的数字签名进行验证，一旦验证通过，客户端便可明确两件事：一，认证服务器的公开密钥的是真实有效的数字证书认证机构。二，服务器的公开密钥是值得信赖的。

此处认证机关的公开密钥必须安全地转交给客户端。使用通信方式时，如何安全转交是一件很困难的事，因此，多数浏览器开发商发布版本时，会事先在内部植入常用认证机关的公开密钥。

以下内容来自群里的朋友，只是做下笔记。

okhttp执行https请求的流程
tcp怎么限流
get请求怎么区分是head和body

https的其实还是基于http协议的加密流程。而http的传输层就是TCP协议。
那么如何限流就把问题抛给了TCP协议的限流拥塞滑动窗口。socket系统调用本质上是一个二到四层调用。也就是从传输层，网络层，数据链路层三个层级的调用。socket的系统调用中file内存文件有一个核心的结构体socket，socket中又是sock，而sock中又有一个tcp_prot结构体，真正处理socket就是由这个协议结构体完成。当我们通过socket系统调用写数据就是通过tcp_sendmsg发送所有拷贝且分片数据到sk_buff上，调用tcp_write_xmit会最后通过拥塞窗口的限流,走到数据链路层的mac的arp协议的获取。有三个概念，tso，拥塞窗口(cwnd)，接收滑动窗口(rwnd)。tso试纸割分片一个过大的数据包切割成几分(sk_buff/mss_now，也就是MTU一个大小1518byte减去ip头和tcp头，可以等到硬件网卡工作)，接着tcp_cwnd_test控制拥塞窗口，本质上就是控制切割大小。拥塞窗口有两个策略，都是首先不断的翻倍增长切割的大小，达到一个阈值就线性增长，这个阈值就是拥塞避免。当线性增长到某一个极限的时候出现丢包。第一个策略就是下降到初始的mss，重新慢启动。第二个策略就是变为当前mss的一半，接着线性增长。拥塞窗口是担心网络拥塞，接收滑动窗口这担心服务器拥塞。接受窗口sk_buff链表分为4部分，1.发送已确认，2.发送没有确认，3.没发送但可发送，4.未发送还不能发送。服务端接受窗口也分为3部分，1.接受已确认。2.等待接受未确认。3.不可接受。接收方会把等待接受未确认的大小交给客户端。客户端会比较这个大小和发送没权人和没发送可发送的大小比较，如果超出了，说明要跳出循环，放到下次发送。

书籍：图解HTTP
文章：www.cnblogs.com/chenguangli…

Http协议-笔记

报文