那些年被忽略的——HTTP的连接（Connection）

• 这是我参与11月更文挑战的第6天，活动详情查看：2021最后一次更文挑战

持久连接

目的

• 在没有持久连接之前，为获取每一个URL指定的资源都必须建立一个独立的TCP连接，从而加重了HTTP服务器的负担，很容易引起互联网的阻塞。

• HTTP持久连接有很多优点

  • 建立与关闭的TCP连接减少，节省了路由器与主机（客户端、服务端、代理、网关、隧道、缓存）的CPU时间，从而节省了主机用于TCP协议控制块的内存。
  • HTTP请求和响应能在连接数上进行管道请求方式，客户端可以发送请求而不用等待以前的请求响应到来之后再发请求，提高了效率，减少了时间。
  • 网络阻塞会被减少，这是由于减少了因TCP链接产生的包的数量。
  • 后续请求的等待时间减少，因为不用在创建TCP连接时的握手耗费时间。
  • HTTP的错误报告不需要关闭TCP连接

操作

• 持久连接是HTTP/1.1的默认方式，除非另有指定，客户端总会和服务端保持持久连接。
• 持久连接提供了一种可以由客户端或服务器通知终止TCP连接的机制。利用Connection头部产生连接信号，一旦出现了终止连接的信号，客户端就不可以向这个连接发送任何的新请求。

管道

• 支持持久连接的客户端可以用管道的方式发送请求，服务器必须按照接收请求的顺序发送响应。
• 只有客户端知道连接是持久连接之后，客户端才能以管道的方式大宋请求。如果服务器在相应所有对应的请求之前关闭了连接，客户端必须准备去重新发送请求。

代理服务器

• 代理正确地实现了Connection头部的属性。
• 代理必须分别与它相连的客户端或源服务器（或是其他代理）指明持久连接，每一个持久连接智能应用于一个传输层连接。

实践后的思考

• 服务器通常有一个值，超过这个时间不再维持处于非活动的连接。代理会选一个较高的值，因为客户端可能会与同一服务器建立多个连接。持久连接方式的采用对于客户端与服务端来说，均未提出任何必须存在超时或给定多长时间的要求。
• 当客户端或服务器希望超时时，应该优雅的关闭连接。客户端与服务端应注意对方是否终止了传输层连接，并适当的予以响应。若客户端或服务器你未能及时检测到对方已终止了连接，将会造成不必要的网络资源浪费。
• 客户端、服务端或代理可能在任意时刻终止传输连接。
• 除了网络、客户端故障，服务器应该至少在每次连接中响应一个请求，不应该在传送响应的中途断开连接。

消息传送的要求

持久连接和流量控制

• HTTP/1.1服务器应该保持持久连接并使用TCP流量控制机制来解决临时过载，而不是在终止连接后让客户端重试，这样会恶化网络阻塞。

监视连接中出错状态的消息

• HTTP/1.1客户端应该应当在发送请求的消息主体的同时监视网络连接是否处于出错状态。若客户端发现了错误，应当立即停止消息主体的传送。
• 若消息主体是以块传输编码方式发送的，可以用长度为零的块和空结尾提前标记报文结束。若消息主体之前有Content-length头部，那么客户端必须关闭连接。

100状态码

• 100的状态码的目的在于允许客户端，在发送此请求消息主体前，判定服务器是否愿意接受发送消息的主体。
• HTTP/1.1客户端的要求：
  • 若客户端想要在发送请求消息主体之前等候100响应，必须发送一个Expect头部，并且值为100-continue。
  • 客户端如果不打算发呆消息主体的请求，那不能发值为100-continue的Expect头部。
  • 若源服务器已经接收到部分或全部请求的消息的主体，源服务器可以不需要发100响应。

总结

• 当了解了HTTP的连接后，除了持久连接，也了解了100状态码。

• 欢迎点赞、评论。