请求行中的内容分为三部分，以空格作为间隔，请求行以\r\n作为结尾(请求行，其实刚好就是一行数据)
第一部分:请求方法:多种多样，描述不同的请求目的。
GET:向服务器请求一个网页实体资源，请求中没有正文，但是也可以向服务器提交娄数据，提交的数据在URL中(安全性低，长度受限)
POST:向服务器提交表单数据，请求中有正文
HEAD:GET和HEAD有什么区别--目的与GET类似，但是不同的是， 实际的响应中不要实体资源，只要响应头部
PUT:更新服务器上的资源 DELETE:删除服务器上的资源
第三部分:协议版本
响应格式:响应行，响应头部，空行，正文
响应行: 协议版本 状态码 状态码描述 \r\n HTTP/1.1 200 0K\r \n
状态码: 用于明确直接的向客户端表示本次请求的处理结果
1xx: 继续请求或者协议切换，101---协议切换
2xx: 请求已经成功处理了，200---成功处理; 206---区间内容处理成功
3xx:表示请求进行了重定向, 301--永久重定向；302--临时重定向；303--查看其他地址 304--not modify
重定向: 一个请求，要请求的资源，被移动到了其他位置。 但要保持原链接依然有效。
空行：间隔头部和正文 正文：响应给客服端的数据
混合加密:
思想:假设是客户端对服务器进行验证
1.服务器生成一对非对称密钥，连接建立成功，通信前，将公钥发送给客户端
2.客户端收到后，使用公钥加密一个随机数A，以及自己支持的对称加密算法
3.服务器收到后，使用私钥进行解密，得到了随机数A，以及对方的对称加密算法
4.服务器向客户端发送一个随机数B，以及自己支持的对称加密算法客户端和服务器，各自根据两个随机数以及支持的对称加密算法，计算出一个对称密钥，走到这一步，对称密钥就协商完毕了. 5.往后的通信使用对称密钥进行加密解密数据传输。
在实际的SSL加密中，身份验证和加密传输是整合在一起的。
CA证书中包含了更多的信息: 通信方的公钥，机构信息，证书颁发机构信息，失效时间.....整体流程:单向验证，以服务端验证为主
1.服务器自己生成一对密钥，拿着公钥，去第三方权威机构颁发证书
2.权威机构根据服务器的公钥，生成一个CA证书，给服务器
3.客户端与服务器建立连接后，通信前，服务器先将CA证书发送给客户端
4.客户端收到CA证书，进行解析验证权威机构是否自己信任，在权威机构验证对方身份，解析出公钥
5.客户端生成一个随机数，使用公钥对随机数+加密算法进行加密，发送给服务器 6.服务器收到数据后，使用私钥进行解密，生成一个自己的随机数，将随机数和加密算法发送给客户端 7.客户端收到数据后，客户端和服务器都有对方的随机数，和自己的随机数，以及加密算法，进行计算得到一个对称密钥 8.往后通信，使用对称密钥进行传输加密
16位源端端口&16位对端端口: 描述通信两端进程
32位序号: 告诉接收端，这条数据在整体数据中的排序 ，接收端根据序号进行排序
32位确认序号: 向发送端进行回复确认，确认序号之前的数据都已经收到了
4位头部长度: 以4字节为单位描述tcp报文头部长度，tcp报头最长是60字节，最小20字节解析过程: 先取出20字节固定长度数据，然后根据头长取出选项数据，..
6位保留:暂时未使用
6位标志位: FIN,SYN,RST,PUSH,ACK,URG
16位窗口大小:用于实现滑动窗口机制，进行流量控制
16位校验和:二进制反码求和算法，校验数据一致性
16位紧急指针: 指向带外优先数据的结束位置
tcp协议特性: 面向连接，可靠传输，提供字节流传输服务面向连接: 通信前，要先建立连接，确保双方都是在线，具有数据收发能力的。
连接管理: 三次握手建立连接，四次挥手断开连接。
三次握手建立连接:通信前，要先建立连接，确保双方具有数据收发能力。
四次挥手断开连接: 通信结束了，会有一个断开连接过程，避免出现意外。
FIN 请求的功能:只能表示不再给对方发送数据(不代表不接收数据)。
CLOSE WAIT: 等待关闭，对方发送了FIN包，已经不再给自己发送数据上层如果这时候还在继续recv，则会读完缓冲区数据后，不再阻塞，而是返回0。 这种情况下就是等待上层针对这种情况的处理。
1.挥手为什么是四次
1. FIN请求只能表示主动关闭方不再发送数据，不代表不再接收数据因此，被动关闭方收到FIN并进行确认后，还有可能会继续发送数据等待上层不再发送数据了，也要关闭套接字了才会发送FIN包因此挥手没有合并为三次
2.一台主机上出现了大量的CLOSE WAIT状态连接，是什么原因? 1.只有收到了FIN请求并进行了确认回复的连接会进入CLOSE WAIT 。 2.一直处于CLOSE WAIT而没有进入下一步状态是因为，上层没有进行关闭套接字操作，也就是没有发送FIN，所以没有进入下一步 。 3.因此原因就是代码中没有针对断开连接的套接字进行关闭处理。
3.TIME WAIT状态有什么用，为什么不直接关闭套接字释放资源? 1.TIME WAIT状态是主动关闭方在发送最后一次ACK后进入的状态 2.如果没有TIME WAIT，主动关闭方直接释放套接字资源，有可能出现新启动的套接字使用了与之前相同的地址信息
3.而上一次连接有可能最后一次ACK会丢失，一旦丢失被动关闭方会重传FIN 4.就会导致上一次通信因为最后一次ACK丢失，而遗留的问题 (重传FIN)对新连接造成影响。
因此不能直接释放资源，需要等待两个MSL时间，针对有可能存在的FIN重传进行处理，并保证上一次通信的所有数据都消失在网络中。
MSL：报文最大生命周期（一个报文在网络中最大能存在的时间），默认60s.
没有必要的性能损失处理机制:
1.滑动窗口机制: 通过协议字段中的窗口大小字段实现的接收方每次接收到数据都会进行确认回复，在确认回复的时候就会计算自己的接收缓冲区中的剩余空间大小，将这个数字放入窗口大小字段中给对方回复。
发送方根据确认回复中的窗口大小字段，确定自己最多发送多少数据
这就是tcp中的流量控制--避免因为发送方发送数据过多导致接收方接收缓冲区溢出而导致的丢包
性能的挽回:
tcp为了保证可靠传输，牺牲了部分传输性能，但是有些性能的损失是没有必要的
1.因为发送数据过多，导致对方缓冲区溢出而丢包
2.因为网络状况的突变，导致大量的丢包重传
3.因为确认应答丢失所导致的重传
流量控制:
停等协议: 发送方发送一条数据后，收到回复才会发送下一条数据
适用于网络状况较差的场景
回退n步协议: 滑动窗口机制决定了tcp数据传输可以管线化传输，可以连续发送多个报文，而在传输过程中，如果出现了丢包，回退n步协议，指的是从丢包的这个数据开始重新对数据进行传输。适用于网络状态一般的场景
选择重传协议: 传输过程中，丢包了，哪个包丢了，就对哪个包重传适
用于网络较好的场景
而发送方，连续收到三条第一条数据的确认回复，则会对第一条数据进行重传
收到三条重传请求，才对数据进行重传，这是因为要考虑第一条数据可能只是网络延迟了，而并没有丢包的情况，因此以3次作为判断基准，给一定的缓冲时间。
性能的挽回：
快速重传协议: 避免每次重传都需要等待超时才进行
延迟发送机制:
解决频繁的小数据发送效率较低的情况，每次发送数据，数据并不会立即被发送而是会等待一小会，在这期间有可能又会有小数据被放到发送缓冲区，小数据就会积累成为大数据，经过一次IO就可以完成传输。减少了1O次数提高了效率。
延迟应答机制:
基于确认应答机制，接收方需要对发送方的每一条数据进行确认回复。而如果直接对数据进行确认回复，大概率数据在缓冲区并没有被取出，因此这时候的回复会导致窗口大小变小，网络的吞吐率降低了 (传输效率降低了) ，因此设计者就设计延迟一会应答，这段延迟的时间中，应用程序就有可能将数据取出，保持窗口不变吞吐率不变，尽可能的总是以最大速率传输数据。
捎带应答机制:
基于确认应答机制，接收方需要对发送方的每一条数据进行确认回复但是每一个回复都是一个最小20字节的报文，也会占据带宽因此设计者认为，如果收到了一条数据后，接收方刚好也有数据要发送给对方，就干脆将这个确认回复与要发送的数据结合到一起 (确认应答也就是个确认序号)发送给对方。这样可以尽可能减少空报文的传输。
粘包问题: 数据在缓冲区中堆积，将多条数据当作一条数据进行处理的过程 粘包产生的本质原因:数据之间缺乏边界管理 tcp粘包原因: tcp在传输层，并不管传输什么数据，只管从缓冲区取合适大小的数据进行操作，没有边界管理。
解决方案: 在应用层，程序员对数据进行边界管理
边界管理: 明确一条数据从哪开始，到哪结束
1.特殊字符间隔:需要对数据中的特殊字符进行编码，避免歧义 2.数据定长:数据固定长度，缺陷就是需要以最大长度定线(浪费较多) 3.数据采用TLV格式:在应用层头部中定义数据的长度(先取头部，根据头部中的长度，决定取多少数据) 。--典型做法：HTTP,UDP
