TPC协议

TPC协议

HTTP协议

概述

1. 超文本传输协议（Hypertext Transfer Protocol，HTTP）是一个简单的请求-响应协议，它通常运行在TCP之上。它指定了客户端可能发送给服务器什么样的消息以及得到什么样的响应。请求和响应消息的头以ASCII形式给出；而消息内容则具有一个类似MIME的格式。

2. HTTP是一个客户端终端（用户）和服务器端（网站）请求和应答的标准（TCP）。通过使用网页浏览器、网络爬虫或者其它的工具，客户端发起一个HTTP请求到服务器上指定端口（默认端口为80）。我们称这个客户端为用户代理程序（user agent）。应答的服务器上存储着一些资源，比如HTML文件和图像。我们称这个应答服务器为源服务器（origin server）。在用户代理和源服务器中间可能存在多个“中间层”，比如代理服务器、网关或者隧道（tunnel）。

3. 尽管TCP/IP协议是互联网上最流行的应用，HTTP协议中，并没有规定必须使用它或它支持的层。事实上，HTTP可以在任何互联网协议上，或其他网络上实现。HTTP假定其下层协议提供可靠的传输。因此，任何能够提供这种保证的协议都可以被其使用。因此也就是其在TCP/IP协议族使用TCP作为其传输层。

   通常，由HTTP客户端发起一个请求，创建一个到服务器指定端口（默认是80端口）的TCP连接。HTTP服务器则在那个端口监听客户端的请求。一旦收到请求，服务器会向客户端返回一个状态，比如"HTTP/1.1 200 OK"，以及返回的内容，如请求的文件、错误消息、或者其它信息。

原理

HTTP协议定义Web客户端如何从Web服务器请求Web页面，以及服务器如何把Web页面传送给客户端。HTTP协议采用了请求/响应模型。客户端向服务器发送一个请求报文，请求报文包含请求的方法、URL、协议版本、请求头部和请求数据。服务器以一个状态行作为响应，响应的内容包括协议的版本、成功或者错误代码、服务器信息、响应头部和响应数据。

HTTP 请求/响应

1. 客户端连接到Web服务器
   一个HTTP客户端，通常是浏览器，与Web服务器的HTTP端口（默认为80）建立一个TCP套接字连接。例如，http://www.baidu.com。

2. 发送HTTP请求
   通过TCP套接字，客户端向Web服务器发送一个文本的请求报文，一个请求报文由请求行、请求头部、空行和请求数据4部分组成。

3. 服务器接受请求并返回HTTP响应
   Web服务器解析请求，定位请求资源。服务器将资源复本写到TCP套接字，由客户端读取。一个响应由状态行、响应头部、空行和响应数据4部分组成。

4. 释放连接TCP连接
   若connection 模式为close，则服务器主动关闭TCP连接，客户端被动关闭连接，释放TCP连接;若connection 模式为keepalive，则该连接会保持一段时间，在该时间内可以继续接收请求;

5. 客户端浏览器解析HTML内容
   客户端浏览器首先解析状态行，查看表明请求是否成功的状态代码。然后解析每一个响应头，响应头告知以下为若干字节的HTML文档和文档的字符集。客户端浏览器读取响应数据HTML，根据HTML的语法对其进行格式化，并在浏览器窗口中显示。

http协议是基于TCP/IP协议之上的应用层协议。

例如：在浏览器地址栏键入URL，按下回车之后会经历以下流程：

1. 浏览器向 DNS 服务器请求解析该 URL 中的域名所对应的 IP 地址;

2. 解析出 IP 地址后，根据该 IP 地址和默认端口 80，和服务器建立TCP连接;

3. 浏览器发出读取文件(URL 中域名后面部分对应的文件)的HTTP 请求，该请求报文作为 TCP 三次握手的第三个报文的数据发送给服务器;

4. 服务器对浏览器请求作出响应，并把对应的 html 文本发送给浏览器;

5. 释放 TCP连接;

6. 浏览器将该 html 文本并显示内容;

   [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-S1ykpXt8-1613794353851)(C:\Users\ASUS\AppData\Roaming\Typora\typora-user-images\1613784415427.png)]

基于 请求-响应 的模式

HTTP协议规定,请求从客户端发出,最后服务器端响应该请求并 返回。换句话说,肯定是先从客户端开始建立通信的,服务器端在没有 接收到请求之前不会发送响应

我们知道HTTP协议是一种单向的网络协议，在建立连接后，仅允许Browser/UserAgent向WebServer发出请求资源后，WebServer才能返回对应的数据，而WebServer不能主动的推送数据给Browser/UserAgent。

最初这么设计HTTP协议的原因是，假设WebServer能主动的推送数据给Browser/UserAgent，那么Browser/UserAgent就太容易受到攻击了，一些广告商也会主动把广告在不经意间强行的传输给客户端，这不能不说是一个灾难。那么单向的HTTP协议给Web应用开发带哪些问题呢？

现在假设我们要开发一个基于Web的应用去获取当前WebServer的实时数据。例如股票实时行情、火车票剩余票数等。这就需要Browser/UserAgent与WebServer之间反复进行HTTP通信，Browser/UserAgent不断的发送请求去获取当前的实时数据。

无状态保存

HTTP是一种不保存状态,即无状态(stateless)协议。HTTP协议 自身不对请求和响应之间的通信状态进行保存。也就是说在HTTP这个 级别,协议对于发送过的请求或响应都不做持久化处理。

使用HTTP协议,每当有新的请求发送时,就会有对应的新响应产 生。协议本身并不保留之前一切的请求或响应报文的信息。这是为了更快地处理大量事务,确保协议的可伸缩性,而特意把HTTP协议设计成 如此简单的。可是,随着Web的不断发展,因无状态而导致业务处理变得棘手 的情况增多了。比如,用户登录到一家购物网站,即使他跳转到该站的 其他页面后,也需要能继续保持登录状态。针对这个实例,网站为了能 够掌握是谁送出的请求,需要保存用户的状态。HTTP/1.1虽然是无状态协议,但为了实现期望的保持状态功能, 于是引入了Cookie技术。有了Cookie再用HTTP协议通信,就可以管 理状态了。有关Cookie的详细内容稍后讲解。

无连接

无连接的含义是限制每次连接只处理一个请求。服务器处理完客户的请求，并收到客户的应答后，即断开连接。采用这种方式可以节省传输时间，并且可以提高并发性能，不能和每个用户建立长久的连接，请求一次相应一次，服务端和客户端就中断了。但是无连接有两种方式，早期的http协议是一个请求一个响应之后，直接就断开了，但是现在的http协议1.1版本不是直接就断开了，而是等几秒钟，这几秒钟是等什么呢，等着用户有后续的操作，如果用户在这几秒钟之内有新的请求，那么还是通过之前的连接通道来收发消息，如果过了这几秒钟用户没有发送新的请求，那么就会断开连接，这样可以提高效率，减少短时间内建立连接的次数，因为建立连接也是耗时的，默认的好像是3秒中现在，但是这个时间是可以通过咱们后端的代码来调整的，自己网站根据自己网站用户的行为来分析统计出一个最优的等待时间。

三次握手，四次挥手

请求

请求方法

GET

向指定的资源发出“显示”请求。使用GET方法应该只用在读取数据，而不应当被用于产生“副作用”的操作中，例如在Web Application中。其中一个原因是GET可能会被网络蜘蛛等随意访问。

HEAD

与GET方法一样，都是向服务器发出指定资源的请求。只不过服务器将不传回资源的本文部分。它的好处在于，使用这个方法可以在不必传输全部内容的情况下，就可以获取其中“关于该资源的信息”（元信息或称元数据）。

POST

向指定资源提交数据，请求服务器进行处理（例如提交表单或者上传文件）。数据被包含在请求本文中。这个请求可能会创建新的资源或修改现有资源，或二者皆有。

PUT

向指定资源位置上传其最新内容。

DELETE

请求服务器删除Request-URI所标识的资源。

TRACE

回显服务器收到的请求，主要用于测试或诊断。

OPTIONS

这个方法可使服务器传回该资源所支持的所有HTTP请求方法。用’*'来代替资源名称，向Web服务器发送OPTIONS请求，可以测试服务器功能是否正常运作。

CONNECT

HTTP/1.1协议中预留给能够将连接改为管道方式的代理服务器。通常用于SSL加密服务器的链接（经由非加密的HTTP代理服务器）。

注意事项：

1. 方法名称是区分大小写的。当某个请求所针对的资源不支持对应的请求方法的时候，服务器应当返回状态码405（Method Not Allowed），当服务器不认识或者不支持对应的请求方法的时候，应当返回状态码501（Not Implemented）。

HTTP服务器至少应该实现GET和HEAD方法，其他方法都是可选的。当然，所有的方法支持的实现都应当匹配下述的方法各自的语义定义。此外，除了上述方法，特定的HTTP服务器还能够扩展自定义的方法。例如PATCH（由 RFC 5789 指定的方法）用于将局部修改应用到资源。

2. 请求方式: get与post请求（通过form表单我们自己写写看）

GET提交的数据会放在URL之后，也就是请求行里面，以?分割URL和传输数据，参数之间以&相连，如EditBook?name=test1&id=123456.（请求头里面那个content-type做的这种参数形式，后面讲） POST方法是把提交的数据放在HTTP包的请求体中.

GET提交的数据大小有限制（因为浏览器对URL的长度有限制），而POST方法提交的数据没有限制.

GET与POST请求在服务端获取请求数据方式不同，就是我们自己在服务端取请求数据的时候的方式不同了，这句废话昂。

URL

超文本传输协议（HTTP）的统一资源定位符将从因特网获取信息的五个基本元素包括在一个简单的地址中：

传送协议。

层级URL标记符号(为[//],固定不变)

访问资源需要的凭证信息（可省略）

服务器。（通常为域名，有时为IP地址）

端口号。（以数字方式表示，若为HTTP的默认值“:80”可省略）

路径。（以“/”字符区别路径中的每一个目录名称）

查询。（GET模式的窗体参数，以“?”字符为起点，每个参数以“&”隔开，再以“=”分开参数名称与数据，通常以UTF8的URL编码，避开字符冲突的问题）

以“#”字符为起点

以http://www.luffycity.com:80/news/index.html?id=250&page=1 为例, 其中：

http，是协议；
www.luffycity.com，是服务器；
80，是服务器上的默认网络端口号，默认不显示；
/news/index.html，是路径（URI：直接定位到对应的资源）；
?id=250&page=1，是查询。
大多数网页浏览器不要求用户输入网页中“http://”的部分，因为绝大多数网页内容是超文本传输协议文件。同样，“80”是超文本传输协议文件的常用端口号，因此一般也不必写明。一般来说用户只要键入统一资源定位符的一部分（www.luffycity.com:80/news/index.html?id=250&page=1）就可以了。

由于超文本传输协议允许服务器将浏览器重定向到另一个网页地址，因此许多服务器允许用户省略网页地址中的部分，比如 www。从技术上来说这样省略后的网页地址实际上是一个不同的网页地址，浏览器本身无法决定这个新地址是否通，服务器必须完成重定向的任务。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-fXRp8H8q-1613794353853)(C:\Users\ASUS\AppData\Roaming\Typora\typora-user-images\1613784551516.png)]

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-UjBsnQXD-1613794353854)(C:\Users\ASUS\AppData\Roaming\Typora\typora-user-images\1613784560031.png)]

响应

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-Ba3XkIOU-1613794353854)(C:\Users\ASUS\AppData\Roaming\Typora\typora-user-images\1613784609368.png)]

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-EsVz1qNp-1613794353855)(C:\Users\ASUS\AppData\Roaming\Typora\typora-user-images\1613784615376.png)]

HTTP状态码

所有HTTP响应的第一行都是状态行，依次是当前HTTP版本号，3位数字组成的状态代码，以及描述状态的短语，彼此由空格分隔。

状态代码的第一个数字代表当前响应的类型：

1xx消息——请求已被服务器接收，继续处理

2xx成功——请求已成功被服务器接收、理解、并接受

3xx重定向——需要后续操作才能完成这一请求

4xx请求错误——请求含有词法错误或者无法被执行

5xx服务器错误——服务器在处理某个正确请求时发生错误

虽然 RFC 2616 中已经推荐了描述状态的短语，例如"200 OK"，“404 Not Found”，但是WEB开发者仍然能够自行决定采用何种短语，用以显示本地化的状态描述或者自定义信息。

HTTPS协议

概述

是以安全为目标的 HTTP 通道，在HTTP的基础上通过传输加密和身份认证保证了传输过程的安全性 [1] 。HTTPS 在HTTP 的基础下加入SSL，HTTPS 的安全基础是 SSL，因此加密的详细内容就需要 SSL。 HTTPS 存在不同于 HTTP 的默认端口及一个加密/身份验证层（在 HTTP与 TCP 之间）。这个系统提供了身份验证与加密通讯方法。它被广泛用于万维网上安全敏感的通讯，例如交易支付等方面 [2] 。

原理

HTTPS 主要由两部分组成：HTTP + SSL / TLS，也就是在 HTTP 上又加了一层处理加密信息的模块。服务端和客户端的信息传输都会通过 TLS 进行加密，所以传输的数据都是加密后的数据。

HTTPS 协议是由 HTTP 加上 TLS/SSL 协议构建的可进行加密传输、身份认证的网络协议，主要通过数字证书、加密算法、非对称密钥等技术完成互联网数据传输加密，实现互联网传输安全保护。设计目标主要有三个。

（1）数据保密性：保证数据内容在传输的过程中不会被第三方查看。就像快递员传递包裹一样，都进行了封装，别人无法获知里面装了什么 [4] 。

（2）数据完整性：及时发现被第三方篡改的传输内容。就像快递员虽然不知道包裹里装了什么东西，但他有可能中途掉包，数据完整性就是指如果被掉包，我们能轻松发现并拒收 [4] 。

（3）身份校验安全性：保证数据到达用户期望的目的地。就像我们邮寄包裹时，虽然是一个封装好的未掉包的包裹，但必须确定这个包裹不会送错地方，通过身份校验来确保送对了地方 [4] 。

流程

① 客户端将它所支持的算法列表和一个用作产生密钥的随机数发送给服务器 [2] ；

② 服务器从算法列表中选择一种加密算法，并将它和一份包含服务器公用密钥的证书发送给客户端；该证书还包含了用于认证目的的服务器标识，服务器同时还提供了一个用作产生密钥的随机数 [2] ；

③ 客户端对服务器的证书进行验证（有关验证证书，可以参考数字签名），并抽取服务器的公用密钥；然后，再产生一个称作 pre_master_secret 的随机密码串，并使用服务器的公用密钥对其进行加密（参考非对称加 / 解密），并将加密后的信息发送给服务器 [2] ；

④ 客户端与服务器端根据 pre_master_secret 以及客户端与服务器的随机数值独立计算出加密和 MAC密钥（参考 DH密钥交换算法） [2] ；

⑤ 客户端将所有握手消息的 MAC 值发送给服务器 [2] ；

⑥ 服务器将所有握手消息的 MAC 值发送给客户端 [2] 。

TPC

传输控制协议（TCP，Transmission Control Protocol）是一种面向连接的、可靠的、基于字节流的传输层通信协议，由IETF的RFC 793 [1] 定义。

TCP三次握手

序号（Seq）：用来标识从TCP源端向目的端发送的字节流，发起方发送数据时对此进行标记。

确认号（ack）：只有ACK标志位为1时，确认序号字段才有效，ack=Seq+1。

ACK标志位：确认序号有效。

SYN标志位：发起一个新连接。

FIN标志位：释放一个连接。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-5c8zuKMD-1613794353856)(C:\Users\ASUS\AppData\Roaming\Typora\typora-user-images\1613784713844.png)]

第一次握手： 客户端主动发起连接请求：发送SYN=1， Seq=x（x一般为1，表示发送了一个序列号为x的数据）。

第二次握手： 服务器端此时结束监听，接收到客户端的连接请求并同意连接：发送SYN=1，ACK=1（表示服务器端收到客户端想要连接的请求），Seq=y，ack=x+1（表示是在收到客户端报文的基础上，将其序号Seq值加1作为本段报文确认号Ack的值）。

第三次握手： 客户端结束SYN-SENT阶段，进入ESTAB-LISHED阶段，并发送报文给服务器端：ACK=1，表示客户端收到服务器端确认收到自己发送连接的请求，Seq=x+1（收到服务器端确认号ack，并将其作为自己的序号值）,ack=y+1（收到服务器的Seq，将Seq+1作为自己的ack）。

TCP/IP： 是互联网相关的各类协议族的总称，比如：TCP，UDP，IP，FTP，HTTP，ICMP，SMTP 等都属于 TCP/IP 族内的协议。

TCP负责发现传输中的问题，一有问题就发出信号，要求重新传输，直到所有数据安全正确地传输到目的地。TCP是一个端到端的面向连接的协议。所以HTTP在开始传输之前，首先需要建立TCP连接，而TCP连接的过程需要所谓的“三次握手”。

TCP四次挥手

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-D0emn3gE-1613794353857)(C:\Users\ASUS\AppData\Roaming\Typora\typora-user-images\1613784738085.png)]

第一次挥手： 客户端想要释放连接，向服务器端发送一段TCP报文，其中：FIN=1，Seq=U；随后客户端进入FIN-WAIT-1阶段，即半关闭阶段。并且停止在客户端到服务器端方向上发送数据，但是客户端仍然能接收从服务器端传输过来的数据。
PS：客户端仍然能发送ACK确认报文。

第二次挥手： 服务器端确认客户端想要释放连接，随后服务器端结束ESTABLISHED阶段，进入CLOSE-WAIT阶段（半关闭状态）并返回一段TCP报文：ACK=1（表示服务器端收到客户端想要释放连接的信号），Seq=V，确认号为ack=U+1；随后服务器端开始准备释放服务器端到客户端方向上的连接。客户端收到从服务器端发出的TCP报文之后，确认了服务器收到了客户端发出的释放连接请求，随后客户端结束FIN-WAIT-1阶段，进入FIN-WAIT-2阶段。
前"两次挥手"既让服务器端知道了客户端想要释放连接，也让客户端知道了服务器端了解了自己想要释放连接的请求。于是，可以确认关闭客户端到服务器端方向上的连接了

第三次挥手： 服务器端自从发出ACK确认报文之后，经过CLOSED-WAIT阶段，做好了释放服务器端到客户端方向上的连接准备，再次向客户端发出一段TCP报文：标记位为FIN，ACK，表示“已经准备好释放连接了”，Seq=W，确认号为ack=U+1；随后服务器端结束CLOSE-WAIT阶段，进入LAST-ACK阶段。并且停止在服务器端到客户端的方向上发送数据，但是服务器端仍然能够接收从客户端传输过来的数据（ACK确认报文）。

第四次挥手： 客户端收到从服务器端发出的TCP报文，确认了服务器端已做好释放连接的准备，结束FIN-WAIT-2阶段，进入TIME-WAIT阶段，并向服务器端发送一段报文：标记位为ACK，表示“接收到服务器准备好释放连接的信号”；序号为Seq=U+1，确认号为Ack=W+1。随后客户端开始在TIME-WAIT阶段等待2MSL。

几点思考：

Q：客户端在发送完ACK确认报文之后，为什么会设置一个时长为2MSL的计时器？
A：当客户端发出最后的ACK确认报文时，并不能确定服务器端能够收到该报文，因此需要等一段时间。MSL指的是Maximum Segment Lifetime：一段TCP报文在传输过程中的最大生命周期。2MSL即是服务器端发出为FIN报文和客户端发出的ACK确认报文所能保持有效的最大时长。服务器端在1MSL内没有收到客户端发出的ACK确认报文，就会再次向客户端发出FIN报文；

Q：为什么是四次挥手，不是三次？
A：因为服务端在LISTEN状态下，收到客户端发送的断开连接的FIN报文后，可能会有数据未发送完成，需要继续发送，因此不能将确认消息和请求关闭消息同时发送，而是会先关闭接收服务回复确认消息，然后继续发送未完消息到客户端，直到发送结束，再发送请求关闭消息。

UDP

概述

UTP----用户数据报协议，是一个简单的面向数据报的运输层协议。

特点

1. 面向无连接(UDP在传输数据报前不用在客户端和服务端之间建议连接)

2. 每个数据包大小限制在64k内(UTP发送数据是将数据分解成多个包进行发送)

3. UTP不提供可靠性(因为是面向无连接)

IN报文和客户端发出的ACK确认报文所能保持有效的最大时长。服务器端在1MSL内没有收到客户端发出的ACK确认报文，就会再次向客户端发出FIN报文；

Q：为什么是四次挥手，不是三次？
A：因为服务端在LISTEN状态下，收到客户端发送的断开连接的FIN报文后，可能会有数据未发送完成，需要继续发送，因此不能将确认消息和请求关闭消息同时发送，而是会先关闭接收服务回复确认消息，然后继续发送未完消息到客户端，直到发送结束，再发送请求关闭消息。

UDP

概述

UTP----用户数据报协议，是一个简单的面向数据报的运输层协议。

特点

1. 面向无连接(UDP在传输数据报前不用在客户端和服务端之间建议连接)

2. 每个数据包大小限制在64k内(UTP发送数据是将数据分解成多个包进行发送)

3. UTP不提供可靠性(因为是面向无连接)

4. 传输速度快(因为不需要建立连接)