详解Http
(1)HyperText Transfer Protocol 超文本传输协议
(2)解释
协议:"协"代表两个人以上,"议"代表一种规范,约束
传输:把A搬到B点,双向协议,我们访问报读的流程:
我们是请求方A,百度就是应答方B,双方约定用HTTP协议传输,brower把请求数据发送给网站,网站在把一些数据返回给浏览器,浏览器在渲染到屏幕,我们就看到图片了
超文本:超越了普通文本的文本呗! 早期的字符 = 图片,视频,压缩包等
1xx:提示信息,说明到现在为止正常,还可以进行后续的请求
2xx:成功状态码,报文收到并正确处理
3xx:重定向
4xx:客户端错误
--400:请求报文有误
--401:请求访问需要有认证信息
--403:服务器禁止访问资源
--404:Not Found,请求的资源在服务器未找到
5xx:服务端错误
(1)Host:域名,可以请求同一台主机的不同域名网站
(2)Connection:Keep-Alive
--:Http/1.1默认采用的是TCP持久连接,可以进行复用
--:为了兼容老版本,需要加上Keep-Alive
(3)Content-Length:服务器响应client时,表明本次的数据长度
(4)Content-type: text/html 返回的数据格式, 客户端也可以用Accept设置接收的类型
(5)Content-Encoding: gzip 返回类型使用什么压缩,客户端也可以用Accept-Encoding设置接收哪些压缩方法
GET:从服务器获取资源(文本,图片,视频等...)
POST:向URI指定的资源提交数据,把我们的[留言文本消息]放入请求体body,再拼接好POST请求头,通过TCP协议发送给服务器
(1)幂等性:多次执行多次操作,那么结果都是[相同]的
(2)GET是安全且幂等:它只是[可读]操作,无论执行多少次,服务器的数据都是安全的,每次的结果都是相同的
(3)POST是不安全且不幂等:新增数据会修改服务器资源,所以是不安全,多次提交会创建多个资源,所以不是幂等的
1.Http协议底层是TCP/IP,所以GET和POST的底层也是TCP/IP,也就时说Get/Post都是TCP连接
2.Get和Post做的事情是一样的,如果给Get加上Request Body,给Post带上url参数,技术上是完全行得通的
3.举个栗子
1.C/S ==== 2K/64K
业界不成文规定:浏览器(大多数)都会限制url的长度在2k个字节,而服务器(大多数)最多处理64k个字节大小的url,超过的部分不处理
2.用Get请求方式,私藏数据在Request Body
(1)有的服务器会绑定卸货,读取数据,有的直接忽略
(2)虽然Get请求方式可以把数据放在Request Body,但是却不能保证一定会被服务器接收
(1)简单:报文格式 == head + body 头部信息也是key-value的形式
(2)灵活易于扩展:
--:状态码和请求头字段都可以由开发人员自定义
--:由于http在应用层(最顶层),那么下层可以随意变化
例子:HTTPS其实就是在应用层和TCP加了一个SSL/TLS的协议
(3)跨平台,应用广泛:从台式机的浏览器到手机的各种APP,都是HTTP的应用,遍地开花
(1)无状态:
描述:好处是服务器不需要额外资源记录这些客户端状态,减轻负担,但是我们登录 == 添加到购物车 == 下单 == 结算这种连贯的操作需要每次都验证一次身份,那很麻烦
解决:使用cookie在请求和响应报文记录客户端的状态
[第一次访问server,server会发放"门牌卡"给client,下次请求,client只要带上这个卡,服务器就认识你了]
(2)url地址的明文传输,不安全
描述:url地址的明文传输,不安全
解决:使用Http + SSL/TLS
(1)早期HTTP/1.0的性能问题
--描述:每发起一个请求,都要新建一个TCP连接(三次握手),而且是串行执行,增加了开销
--解决:HTTP/1.1采用了长连接,减少了连接重复的新建和断开,减轻了服务器的负担
(2)管道网络通讯
--优化串行请求:Http/1.1的长连接是基于"管道"通讯,在同一个TCP连接可以发起多个请求,之前的TCP连接时A请求后等待服务器返回,再发送B请求
--产生问题:但是服务器并不是并发处理请求,而是按照排队顺序执行,也叫做[队头堵塞],相当于高速路上堵车了
(1)安全:HTTP是明文传输,存在安全风险问题,HTTPS在TCP三次握手之后还需要进行SSL/TLS的握手过程,在进行加密报文传输
(2)端口:HTTP的端口是80, HTTPS的端口是443
(3)CA证书:HTTPS协议需要向CA机构申请数字证书,来保证服务器是可信的
(1)优化
--长连接:TCP长连接改善了HTTP/1.0短连接不断创建,断开连接造成的性能开销
--pipeline:支持管道pipeline网络传输,只要第一个请求出去了,不必等它回来就可以请求第二个,减少了整体的响应时间
(2)缺点
--头部:请求头部Header未压缩发送,而且每次都需要发送相同的头部造成浪费多
--队头阻塞:server按照请求顺序来响应,若服务器慢,导致client一直请求不到数据
--没有优先级控制
(1)HTTPS安全:HTTP/2.0是基于HTTPS的,安全性提高
(2)HPACK算法-头部压缩:若你同时发送多个请求,他们的头是一样的,那么协议会帮你消除重复部分
HPACK算法:client和server共同维护一张消息表,所有字段会存入这个表并生成一个索引号,发送只需要传索引号即可
(3)二进制的数据帧:HTTP/1.1是(报文首部+空行+报文主体),HTTP/2换成(头信息帧+数据帧),好处是接收报文后无需将明文报文转成二进制,对计算机来说可以提高传输效率
(4)数据流:
--非顺序:连接中连续数据包不是按照顺序发送,可能属于不同响应,
--流编号:每个请求对应一个数据流(有独立编号),客户端为奇数编号,服务端为偶数编号,客户端可以指定数据流的优先级
(5)多路复用:
--并发处理请求:移除了HTTP/1.1的串性请求,可以并发的回应多个请求,解决了[队头阻塞]问题
--例子:在TCP连接中,server收到A(耗时长),B请求,于是server先回应A已处理部分,在回应B,继续回应A的剩余部分
(6)服务器推送 server push,Cache push
--:Http/2改善了传统的[请求-应答]工作模式,服务器可主动向client发送消息
--:当brower请求HTML时,会提前把js,css静态资源主动发给client,减低延时
问题:
(1)HTTP/1.1丢包情况:在pipeline传输中有一个请求阻塞了,那么在队列后请求会统统被阻塞住了
(2)HTTP/2丢包情况: 多路复用一个TCP连接,一旦发生丢包,所有的请求都会阻塞住
解决:
(1)HTTP/3将HTTP下层的TCP协议改成了UDP,UDP是不管顺序和有无丢包的,所以不会出现HTTP/1.1的[队头阻塞]和HTTP/2的丢包重传问题
(2)UDP是不可靠连接,但基于 UDP 的 QUIC 协议 可以实现类似 TCP 的可靠性传输。
HTTP1、1.1、2、3的特性简述
HTTP(HyperText Transfer Protocol，超文本传输协议)是一种主要由web使用的协议规范，完成从客户端到服务器端的一系列运作流程。
HTTP协议是基于TCP协议开发的，在网络传输模型中属于应用层的内容。
HTTP/1.0协议最早于1996年正式使用，其主要特点为：
HTTP/1.1协议于1997年正式使用，主要是优化并且扩展了HTTP/1.0的内容，主要特点为
由于HTTP1 HTTP1.x HTTP2都是基于TCP开发的，其中的TCP握手问题就无法避免，为了解决这个问题，Google 就另起炉灶搞了一个基于 UDP 协议的 QUIC 协议，并且使用在了 HTTP/3 上。其特点主要为：
以上内容均为笔者在看了文章后以自己的理解讲的内容，如有错误，请不吝指正
HTTP3 为什么比 HTTP2 靠谱？ | 技术头条
HTTP1.0、HTTP1.1 和 HTTP2.0 的区别
HTTP/2之服务器推送(Server Push)最佳实践
协议确认机制TACK的通俗解析
搞计算机网络研究的人都知道，传输层协议最经典的问题就是怎么做 拥塞控制 （Congestion Control）。这玩意做了三十多年还是经久不衰，新人老人前赴后继，近年来又如雨后春笋般出现了BBR，Copa，PCC， Indigo等算法，在不同的场景和目标中各显神通。
在数据传输的过程中，人们通常关注正向的数据报文传输性能，却很少关心反向路径上确认报文ACK的传输。然而，高吞吐和低时延往往与ACK的机制设计息息相关。例如，发生拥塞时，我们依赖ACK及时、准确地反馈连接状态，从而调整发送速率；发生丢包时，我们依赖ACK通知包到达信息，从而进行丢包重传。
拥塞控制已经“杀”成了一片红海，而作为协议的另一个重要模块 协议确认机制 ，却还是一片处女地。
今年我们在SIGCOMM2020上提出了一种新型的传输协议确认机制（ACK Scheme）： TACK ，今天我想通过这篇博文给大家简单地对TACK机制进行通俗化的解析，算作导读。
进入正题。
作为万物互联 “最后100米”的通信网络技术，无线局域网（WLAN）技术催生了各式各样新型的移动应用。无论是通过无线路由器把手机、平板、电脑和电视等智能化设备接入到互联网，还是通过WiFi直连技术架起设备与设备之间的捷径，WLAN为生活数字化和新型应用（如4K无线投屏、AR/VR交互式游戏等）的涌现，提供了无限可能。
WLAN最常用的技术就是WiFi。WiFi通常工作在非授权公共频段（2.4GHz或5GHz），非常容易受到“外部干扰”。这种干扰将造成网络质量突发性劣化和间歇式丢包，导致用户体验下降，例如视频应用可能出现花屏、卡顿，甚至业务中断。
业界针对无线传输协议的优化，通常更关注“外部干扰”，即采取某种算法应对网络抖动或丢包。然而，无线传输过程中还存在所谓的“内部干扰”——同一连接中ACK报文对数据报文的干扰。
传统传输协议TCP因为要保证可靠，在发送数据报文的同时，难以避免地频繁发送ACK报文。另一方面，WiFi的半双工特性和冲突避免机制，造成ACK报文与和数据报文形成了直接的资源竞争，在传统TCP的ACK机制下，控制报文（ACK）几乎要占用将近一半的可用频谱资源。而且，带宽越大，“内部干扰”越严重。
在这种情况下，减少ACK报文的数目从而降低“内部干扰”，不仅可以提高无线传输的有效带宽利用率，而且还可以在弱网下将有限的宝贵传输资源留给数据报文。
然而，传统TCP依赖于高频度的ACK进行传输控制，简单粗暴地减少ACK的数目，却又可能造成滑窗效率低下、缓冲区压力倍增、以及应用响应时延增加。具体表现为数据突发、窗口更新缓慢、时延评估不准确、丢包恢复鲁棒性下降等。
另外，注意到，无线网络同时面临“外部干扰”和“内部干扰”，传输协议如果只强化抗“内部干扰”的手段，就不可避免会降低其抗“外部干扰”的能力。
以上这些矛盾点都使得问题极具挑战。
这篇文章提出“TACK”(Tame ACK，驯服的确认机制)机制，不仅可以最小化ACK的数目，而且还保证传输控制过程的井然有序，正所谓“鱼与熊掌兼得”。
TACK机制颠覆了传统协议确认机制的“简单粗暴”和固有设定，赋予了ACK报文更多的智能和灵活性。其设计原理，可以简单地理解成三点： 1）多ACK种类适应不同场景需求；2）ACK按需携带更多必要的信息；从而实现：3）更少但足够的ACK数目。
具体来说，引入一种“即时ACK”报文加快传输控制对即时事件（例如丢包）的反馈和响应，同时，引入一种高度自适应的“周期ACK”报文保证反馈的鲁棒性和可靠性。这种“周期ACK”报文是以时钟周期触发的，而并非以包接收或者超时等事件触发，这种ACK的数量不会跟吞吐成比例，也就不会造成“内部干扰”随着吞吐增大而增大。
“即时ACK”报文和“周期ACK”相辅相成、互相补充和高效协同，加上基于TACK机制的丢包恢复、时延探测和速率控制算法，可以保证丢包恢复的鲁棒性、时延探测的准确性以及速率控制高效性。
TACK机制作为一种创新的传输协议确认机制，可以在不同的协议载体（例如TCP/UDP/QUIC）上进行实现。我所在的华为计算机网络与协议LAB创新团队，依托其创新的用户态极简协议，为华为全场景生态提供了高效的连接通道。例如，自华为手机系统EMUI 9.1以来，华为、荣耀旗舰手机和智慧屏等多余款产品均采用了基于TACK的极简协议，使得其高清视频和游戏投屏体验得到显著改善。
在SIGCOMM的众多研究方向中，传输协议TCP优化是一个经典的课题，与TCP优化相关的工作必须达到一个极高的“阈值”才可能被录用。
笔者论文“TACK: Improving Wireless Transport Performance by Taming Acknowledgments”作为传输协议方向的文章成功入围，多年苦心钻研没有白费，努力有被看到，不禁备感幸运。
这篇文章除了得到谭焜博士和郑凯博士的指导外，还受到了清华大学徐恪教授也就是我博士导师的财力和学术上的大力支持，感激无法言表。这篇文章也受到了斯坦福大学Keith Winstein的指导和支持，Keith在自己的[个人主页]()是这么介绍我们的合作过程的：
更多的细节可以阅读论文： Tong Li, Kai Zheng, Ke Xu, Rahul Arvind Jadhav, Tao Xiong, Keith Winstein, Kun Tan. “TACK: Improving Wireless Transport Performance by Taming Acknowledgments.” Proceedings of the 2020 Conference of the ACM Special Interest Group on Data Communication (ACM SIGCOMM), pp. 15-30, 2020.
也可以访问我的主页，获取PPT和视频资料：
快速了解UDP协议
互联网工程任务组（IETF）官员透露，HTTP-over-QUIC实验协议将重命名为HTTP/3，并有望成为HTTP协议的第三个正式版本。
UDP协议被广泛用到对网络数据传输的实时性很高，对数据准确性不是非常高的场合，并且如今网络物理介质的高速提升（光纤）降低了数据丢包的机率，并且当网络状况很好的情况下，UDP的缺点又可以很好的大程度上的被改善。因此UDP协议发展前途无量。
所以，作为新一代HTTP协议的底层，要不要重温下？
UDP是什么？
UDP是User Datagram Protocol的缩写，是一种用户数据报协议，又称为用户数据报文协议。区别于TCP是面向连接的协议，UDP是一个简单的面向数据报的传输层协议，UDP的发起和接受是不需要经过连接的，仅仅只需要发送在对应端口上进行监听接受即可，不需要两个客户端一定是连接的
UDP传输不可靠的原因有五点：
TCP协议和UDP协议的区别是什么？
常见问题：QQ用的是TCP还是UDP？
QQ采用的通信协议以UDP为主，辅以TCP协议。QQ并不是完全基于UDP实现，比如在使用QQ进行文件传输等活动的时候，就会使用TCP作为可靠传输的保证。
由于QQ的服务器设计容量是海量级的应用，一台服务器要同时容纳十几万的并发连接，因此服务器端只有采用UDP协议与客户端进行通讯才能保证这种超大规模的服务。
QQ客户端之间的消息传送也采用了UDP模式，因为国内的网络环境非常复杂，而且很多用户采用的方式是通过代理服务器共享一条线路上网的方式，在这些复杂的情况下，客户端之间能彼此建立起来TCP连接的概率较小，严重影响传送信息的效率。而UDP包能够穿透大部分的代理服务器，因此QQ选择了UDP作为客户之间的主要通信协议。
采用UDP协议，通过服务器中转方式。大家都知道，UDP协议是不可靠协议，它只管发送，不管对方是否收到的，但它的传输很高效。但是，作为聊天软件，怎么可以采用这样的不可靠方式来传输消息呢？于是，腾讯采用了上层协议来保证可靠传输：如果客户端使用UDP协议发出消息后，服务器收到该包，需要使用UDP协议发回一个应答包。如此来保证消息可以无遗漏传输。之所以会发生在客户端明明看到“消息发送失败”但对方又收到了这个消息的情况，就是因为客户端发出的消息服务器已经收到并转发成功，但客户端由于网络原因没有收到服务器的应答包引起的。
之所以当时应用UDP，最本质上UDP的优势还是带宽的利用。这一切要回归到99~03年的网络状况，当时网络的特点就是接入带宽很窄而且抖动特别厉害。所谓抖动可能是多方面的，例如延时突发性地暴增、也有可能是由于路由层面的变化突然导致路由黑洞，还各种等等等等的问题。TCP因为拥塞控制、保证有序等原因，在这种网络状态上对带宽的利用是非常低的。而且因为网络抖动的原因，应用层心跳超时，应用层主动断掉socket之后TCP需要三次握手才能重新建立链接，一旦出现频繁的小抖动就会使得带宽利用更低。而等待四次挥手的时间，也会占用服务器上宝贵的资源。
总结来说，当网络差到一定程度了，TCP的优势反而会成为劣势。
http和https的区别？http与TCP/IP区别？http/TCP三次握手四次挥手
https, 全称Hyper Text Transfer Protocol Secure，相比http，多了一个secure，这一个secure是怎么来的呢？这是由TLS（SSL）提供的，这个又是什么呢？估计你也不想知道。大概就是一个叫openSSL的library提供的。https和http都属于application layer，基于TCP（以及UDP）协议，但是又完全不一样。TCP用的port是80， https用的是443（值得一提的是，google发明了一个新的协议，叫QUIC，并不基于TCP，用的port也是443， 同样是用来给https的。谷歌好牛逼啊。）总体来说，https和http类似，但是比http安全。
http缺省工作在TCP协议80端口(需要国内备案），用户访问网站http://打头的都是标准http服务，http所封装的信息都是明文的，通过抓包工具可以分析其信息内容，如果这些信息内容包含你的银行卡账号、密码，你肯定无法接受这种服务，那有没有可以加密这些敏感信息的服务呢？那就是https！
https是http运行在SSL/TLS之上，SSL/TLS运行在TCP之上。所有传输的内容都经过加密，加密采用对称加密，但对称加密的密钥用服务器方的证书进行了非对称加密。此外客户端可以验证服务器端的身份，如果配置了客户端验证，服务器方也可以验证客户端的身份。
https缺省工作在tcp协议443端口，它的工作流程一般如以下方式：
1、完成tcp三次同步握手；
2、客户端验证服务器数字证书，通过，进入步骤3；
3、DH算法协商对称加密算法的密钥、hash算法的密钥；
4、SSL安全加密隧道协商完成；
5、网页以加密的方式传输，用协商的对称加密算法和密钥加密，保证数据机密性；用协商的hash算法进行数据完整性保护，保证数据不被篡改。
附：https一般使用的加密与hash算法如下：
非对称加密算法：RSA，DSA/DSS
对称加密算法：AES，RC4，3DES
hash算法：MD5，SHA1，SHA256
如果https是网银服务，以上SSL安全隧道成功建立才会要求用户输入账户信息，账户信息是在安全隧道里传输，所以不会泄密！
TPC/IP协议是传输层协议，主要解决数据如何在网络中传输，而HTTP是应用层协议，主要解决如何包装数据。Web使用HTTP协议作应用层协议，以封装HTTP 文本信息，然后使用TCP/IP做传输层协议将它发到网络上。
下面的图表试图显示不同的TCP/IP和其他的协议在最初OSI（Open System Interconnect）模型中的位置：
CA证书是什么？
CA（Certificate Authority）是负责管理和签发证书的第三方权威机构，是所有行业和公众都信任的、认可的。
CA证书，就是CA颁发的证书，可用于验证网站是否可信（针对HTTPS）、验证某文件是否可信（是否被篡改）等，也可以用一个证书来证明另一个证书是真实可信，最顶级的证书称为根证书。除了根证书（自己证明自己是可靠），其它证书都要依靠上一级的证书，来证明自己。
https大致过程：
1、建立服务器443端口连接 ；
2、SSL握手：随机数，证书，密钥，加密算法；
3、发送加密请求 ；
4、发送加密响应；
5、关闭SSL；
6、关闭TCP.
SSL握手大致过程：
1、客户端发送随机数1，支持的加密方法（如RSA公钥加密）；
2、服务端发送随机数2，和服务器公钥，并确认加密方法；
3、客户端发送用服务器公钥加密的随机数3；
4、服务器用私钥解密这个随机数3，用加密方法计算生成对称加密的密钥给客户端；
5、接下来的报文都用双方协定好的加密方法和密钥，进行加密.
1、TCP面向连接（如打电话要先拨号建立连接）;UDP是无连接的，即发送数据之前不需要建立连接
2、TCP提供可靠的服务。也就是说，通过TCP连接传送的数据，无差错，不丢失，不重复，且按序到达;UDP尽最大努力交付，即不保证可靠交付
3、TCP面向字节流，实际上是TCP把数据看成一连串无结构的字节流（流模式）;UDP是面向报文的（报文模式），UDP没有拥塞控制，因此网络出现拥塞不会使源主机的发送速率降低（对实时应用很有用，如IP电话，实时视频会议等）
4、每一条TCP连接只能是点到点的;UDP支持一对一，一对多，多对一和多对多的交互通信
5、TCP要求系统资源较多，UDP较少。TCP首部开销20字节;UDP的首部开销小，只有8个字节
SYN：同步序列编号; ACK=1: 确认序号 ; FIN附加标记的报文段（FIN表示英文finish）
一个TCP连接必须要经过三次“对话”才能建立起来，其中的过程非常复杂，只简单的 描述下这三次对话的简单过程：主机A向主机B发出连接请求数据包：“我想给你发数据，可以吗？”，这是第一次对话；主机B向主机A发送同意连接和要求同步 （同步就是两台主机一个在发送，一个在接收，协调工作）的数据包：“可以，你什么时候发？”，这是第二次对话；主机A再发出一个数据包确认主机B的要求同 步：“我现在就发，你接着吧！”，这是第三次对话。三次“对话”的目的是使数据包的发送和接收同步，经过三次“对话”之后，主机A才向主机B正式发送数据。
为什么需要“三次握手”?
在谢希仁著《计算机网络》第四版中讲“三次握手”的目的是“ 为了防止已失效的连接请求报文段突然又传送到了服务端，因而产生错误 ”。在另一部经典的《计算机网络》一书中讲“三次握手”的目的是为了解决“网络中存在延迟的重复分组”的问题。这两种不一样的表述其实阐明的是同一个问题。
谢希仁版《计算机网络》中的例子是这样的，“已失效的连接请求报文段”的产生在这样一种情况下：client发出的第一个连接请求报文段并没有丢失，而是在某个网络结点长时间的滞留了，以致延误到连接释放以后的某个时间才到达server。 本来这是一个早已失效的报文段。但server收到此失效的连接请求报文段后，就误认为是client再次发出的一个新的连接请求。于是就向client发出确认报文段，同意建立连接。假设不采用“三次握手”，那么只要server发出确认，新的连接就建立了。由于现在client并没有发出建立连接的请求，因此不会理睬server的确认，也不会向server发送数据。但server却以为新的运输连接已经建立，并一直等待client发来数据。这样，server的很多资源就白白浪费掉了。 采用“三次握手”的办法可以防止上述现象发生。例如刚才那种情况，client不会向server的确认发出确认。server由于收不到确认，就知道client并没有要求建立连接。”。 主要目的防止server端一直等待，浪费资源。
为什么需要“四次挥手”？
可能有人会有疑问，在tcp连接握手时为何ACK是和SYN一起发送，这里ACK却没有和FIN一起发送呢。原因是 因为tcp是全双工模式，接收到FIN时意味将没有数据再发来，但是还是可以继续发送数据。
握手，挥手过程中各状态介绍:
3次握手过程状态：
LISTEN: 这个也是非常容易理解的一个状态，表示服务器端的某个SOCKET处于监听状态，可以接受连接了。
SYN_SENT : 当客户端SOCKET执行CONNECT连接时，它首先发送SYN报文，因此也随即它会进入到了SYN_SENT状态，并等待服务端的发送三次握手中的第2个报文。SYN_SENT状态表示客户端已发送SYN报文。（发送端）
SYN_RCVD : 这个状态与SYN_SENT遥想呼应这个状态表示接受到了SYN报文，在正常情况下，这个状态是服务器端的SOCKET在建立TCP连接时的三次握手会话过程中的一个中间状态，很短暂，基本上用netstat你是很难看到这种状态的，除非你特意写了一个客户端测试程序，故意将三次TCP握手过程中最后一个 ACK报文不予发送。因此这种状态时，当收到客户端的ACK报文后，它会进入到ESTABLISHED状态。（服务器端）
ESTABLISHED ：这个容易理解了，表示连接已经建立了。
4次挥手过程状态：（可参考下图）：
FIN_WAIT_1: 这个状态要好好解释一下，其实FIN_WAIT_1和FIN_WAIT_2状态的真正含义都是表示等待对方的FIN报文。而这两种状态的区别是： FIN_WAIT_1状态实际上是当SOCKET在ESTABLISHED状态时，它想主动关闭连接，向对方发送了FIN报文，此时该SOCKET即进入到FIN_WAIT_1状态。而当对方回应ACK报文后，则进入到FIN_WAIT_2状态， 当然在实际的正常情况下，无论对方何种情况下，都应该马上回应ACK报文，所以FIN_WAIT_1状态一般是比较难见到的，而FIN_WAIT_2状态还有时常常可以用netstat看到。（主动方）
FIN_WAIT_2： 上面已经详细解释了这种状态，实际上FIN_WAIT_2状态下的SOCKET，表示 半连接 ，也即有一方要求close连接，但另外还告诉对方，我暂时还有点数据需要传送给你(ACK信息)，稍后再关闭连接。（主动方）
TIME_WAIT: 表示收到了对方的FIN报文，并发送出了ACK报文 ，就等2MSL后即可回到CLOSED可用状态了。如果FIN_WAIT_1状态下，收到了对方同时带FIN标志和ACK标志的报文时，可以直接进入到TIME_WAIT状态，而无须经过FIN_WAIT_2状态。（主动方）
CLOSING（比较少见）: 这种状态比较特殊，实际情况中应该是很少见，属于一种比较罕见的例外状态。正常情况下，当你发送FIN报文后，按理来说是应该先收到（或同时收到）对方的 ACK报文，再收到对方的FIN报文。但是CLOSING状态表示你发送FIN报文后，并没有收到对方的ACK报文，反而却也收到了对方的FIN报文。什么情况下会出现此种情况呢？其实细想一下，也不难得出结论：那就是如果双方几乎在同时close一个SOCKET的话，那么就出现了双方同时发送FIN报文的情况，也即会出现CLOSING状态，表示双方都正在关闭SOCKET连接。
CLOSE_WAIT: 这种状态的含义其实是表示在等待关闭。怎么理解呢？ 当对方close一个SOCKET后发送FIN报文给自己，你系统毫无疑问地会回应一个ACK报文给对方，此时则进入到CLOSE_WAIT状态。接下来呢，实际上你真正需要考虑的事情是察看你是否还有数据发送给对方，如果没有的话，那么你也就可以 close这个SOCKET，发送FIN报文给对方，也即关闭连接。 所以你在 CLOSE_WAIT状态下，需要完成的事情是等待你去关闭连接。 （被动方）
LAST_ACK: 这个状态还是比较容易好理解的，它是被动关闭一方在发送FIN报文后，最后等待对方的ACK报文。当收到ACK报文后，也即可以进入到CLOSED可用状态了。（被动方）
CLOSED: 表示连接中断。
TCP的具体状态图可参考：
Google翻译能用吗QUIC是什么？
在Google新版的Chrome浏览器中，支持QUIC协议，在 Chrome 浏览器中打开“实验性功能”页面（chrome://flags/），启用“实验性 QUIC 协议”和“经由实验性 QUIC 协议发出的 HTTPS 请求”，重启浏览器后可以正常登陆 Google 相关服务(被DNS污染的除外)。对于被DNS污染的Google服务，还需要设置Hosts的IP，然后通过HTTPS才能访问。
QUIC的主要特点包括，具有SPDY（SPDY是谷歌研制的提升HTTP速度的协议，是HTTP/2.0的基础）所有的优点；0-RTT连接；减少丢包；前向纠错，减少重传时延；自适应拥塞控制， 减少重新连接；相当于TLS加密。
0条大神的评论