在我之前的文章中，我们介绍了一些HTTP的基础知识，例如URL方案，状态代码和请求/响应头。以此作为我们的基础，我们将介绍HTTP的更好的方面，如连接处理，身份验证和HTTP缓存。这些主题相当广泛，但我们将介绍最重要的位。
HTTP连接
必须在客户端和服务器之间建立连接，才能相互通信，而HTTP使用可靠的TCP传输协议进行连接。默认情况下，Web流量使用TCP端口80. TCP流被分解为IP数据包，并确保这些数据包始终以正确的顺序到达。HTTP是通过TCP的应用层协议，它是通过IP。
HTTPS是HTTP的安全版本，在称为TLS或SSL（传输层安全或安全套接字层）的HTTP和TCP之间插入一个附加层。HTTPS默认通过端口443进行通信，本文稍后将会看到HTTPS。
HTTP连接被识别<source-IP, source-port>和<destination-IP, destination-port>。在客户端上，HTTP应用程序由<IP, port>元组标识。建立两个端点之间的连接是一个多步骤的过程，涉及到如下：
- 通过DNS从主机名解析IP地址
- 建立与服务器的连接
- 发送请求
- 等待回应
- 关闭连接
服务器负责始终使用正确的标头和响应进行响应。
在HTTP / 1.0中，所有连接在单个事务之后都被关闭。因此，如果客户端想要从同一台服务器请求三个独立的映像，则它会与远程主机建立三个单独的连接。从上图可以看出，这可能会引入大量的网络延迟，从而产生一个次优的用户体验。
为了减少连接建立的延迟，HTTP / 1.1引入了持久连接，长时间的连接保持打开，直到客户端关闭它们。HTTP / 1.1中的持久连接是默认连接，并且单个事务连接需要客户端设置Connection: close请求头。这将通知服务器在发送响应后关闭连接。
除了持续连接之外，浏览器/客户端也采用一种称为并行连接的技术来最大限度地减少网络延迟。并行连接的古老概念涉及创建一个连接池（通常以六个连接为限）。如果客户端需要从网站下载6个资产，客户端将进行六个并行连接来下载这些资产，从而导致更快的周转时间。对于串行连接来说，这是一个巨大的改进，客户端只有在完成先前资产的下载后才下载资产。
并行连接与持续连接相结合，是今天解决网络延迟最小化以及在客户端上创造平滑体验的答案。有关HTTP连接的深入处理，请参阅HTTP规范的“ 连接”部分。
服务器端连接处理
服务器主要监听传入连接，并在收到请求时处理它们。业务涉及：
- 建立一个套接字开始侦听端口80（或其他端口）
- 接收请求并解析消息
- 处理响应
- 设置响应头
- 将响应发送给客户端
- 如果
Connection: close发现请求标头，请关闭连接
当然，这并不是详尽的操作列表。大多数应用程序/网站需要知道谁发出请求以创建更多的自定义响应。这是识别和认证的领域。
识别和认证
HTTP是通过TCP的应用层协议，它是通过IP。
几乎必须知道谁连接到服务器来跟踪应用程序或站点的使用情况以及用户的一般交互模式。识别的前提是为了提供个性化的体验来定制响应; 当然，服务器必须知道用户是谁才能提供该功能。
服务器可以通过几种不同的方式来收集这些信息，大多数网站都使用这些方法的混合：
- 请求头：
From，Referer，User-Agent-我们在看到这些标题1部分。 - Client-IP - 客户端的IP地址
- 胖网址 - 通过修改URL并重定向到每个点击上的不同URL来存储当前用户的状态; 每个点击基本上累积状态。
- 饼干 - 最流行和非侵入性的方法。
Cookie允许服务器通过Set-Cookie响应头附加任意信息以用于外发响应。一个cookie设置有一个或多个name = value对，以分号（;）分隔，如同Set-Cookie: session-id=12345ABC; username=nettuts。
服务器也可以限制cookie来具体的domain和path，它可以使他们执着与expires价值。Cookie是由浏览器向服务器提出的每个请求自动发送，并在浏览器确保了只有domain-和path特异性饼干请求中发送。请求头Cookie: name=value [; name2=value2]用于将这些Cookie发送到服务器。
识别用户的最佳方式是要求他们注册并登录，但实现此功能需要开发人员以及用户的一些努力。
像OAuth这样的技术简化了这种类型的功能，但它仍然需要用户同意才能正常工作。认证在这里扮演着重要的角色，它可能是识别和验证用户的唯一方法。
认证
HTTP确实支持称为基本身份验证的基本形式的身份验证，以及更安全的摘要身份验证。
在基本身份验证中，服务器最初使用WWW-Authenticate响应头和401 Unauthorized状态码拒绝客户端的请求。看到此标题后，浏览器会显示登录对话框，提示输入用户名和密码。该信息以Authentication请求头中的base-64编码格式发送。如果凭据有效，服务器现在可以验证请求并允许访问。某些服务器也可能发送Authentication-Info包含其他身份验证详细信息的标头。
基本认证的推论是代理认证。代替Web服务器，中间代理请求授权挑战。代理发送Proxy-Authenticate带有407 Unauthorized状态码的标头。作为回报，客户端应该通过Proxy-Authorization请求头发送凭据。
Digest认证与Basic类似，并使用WWW-Authenticate与Authorization头部相同的握手技术，但Digest使用更安全的散列函数来加密用户名和密码（通常使用MD5或KD摘要功能）。虽然Digest认证应该比Basic更安全，但由于其简单性，网站通常使用基本认证。为了减轻安全问题，Basic Auth与SSL结合使用。
安全HTTP
HTTPS协议在网络上提供安全连接。知道您使用HTTPS的最简单的方法是检查浏览器的地址栏。HTTPs的安全组件涉及在HTTP和TCP之间插入一层加密/解密。这是安全套接字层（SSL）或改进的传输层安全（TLS）。
SSL使用强大的加密形式，使用RSA和公钥加密。由于安全交易在网络上非常重要，所以基于标准的公钥基础设施（PKI）的推出已经进行了很久。
现有的客户机/服务器不需要改变他们处理消息的方式，因为大部分的辛勤工作都发生在SSL层。因此，您可以使用基本身份验证开发Web应用程序，并通过切换到https://协议自动获取SSL的优点。但是，要使Web应用程序通过HTTPS工作，您需要在服务器上部署一个正常的数字证书。
证书
就像您需要身份证以显示您的身份一样，Web服务器需要一个数字证书来识别自己。证书（或“证书”）由证书颁发机构（CA）颁发，并在网络上保证您的身份。CA是PKI的守护者。最常见的证书形式是X.509 v3标准，其中包含以下信息：
- 证书颁发者
- 用于证书的算法
- 创建此证书的主题名称或组织
- 该主题的公钥信息
- 认证机构签名，使用指定的签名算法
当客户端通过HTTPS发出请求时，它首先尝试在服务器上找到证书。如果找到证书，它将尝试根据其已知的CA列表进行验证。如果它不是列出的CA之一，它可能会向用户显示一个对话框，警告网站的证书。
一旦证书被验证，SSL握手是完整的，安全的传输是有效的。
HTTP缓存
普遍同意，做同样的工作两次是浪费的。这是HTTP缓存概念的指导原则，HTTP缓存是HTTP网络基础设施的基础。由于大多数操作都是通过网络进行的，所以缓存有助于节省时间，成本和带宽，并提供改进的网络体验。
缓存在网络基础架构中的几个地方使用，从浏览器到源服务器。取决于它所在的位置，缓存可以分为：
- 私人：在浏览器中，缓存用户名，密码，URL，浏览历史记录和网页内容。它们通常小而且对用户具体。
- 公共：部署为服务器和客户端之间的缓存代理。这些更大，因为它们服务于多个用户。通常的做法是在客户端和源服务器之间保留多个缓存代理。这有助于为经常访问的内容提供服务，同时仍然允许不经常需要的内容访问服务器。
缓存处理
不管高速缓存位于何处，维护缓存的过程非常相似：
- 接收请求消息。
- 解析 URL和标题。
- 查找本地副本; 否则，在本地获取和存储
- 进行新鲜度检查以确定缓存中内容的年龄; 仅在必要时才提出刷新内容的请求。
- 从缓存的主体和更新的标头创建响应。
- 将响应发送回客户端。
- （可选）记录事务。
当然，服务器负责始终使用正确的标头和响应进行响应。如果一个文档没有改变，服务器应该用一个304 Not Modified。如果缓存的副本已过期，它应该生成一个新的响应，更新的响应头并返回200 OK。如果资源被删除，它应该回来404 Not Found。这些响应有助于调整缓存，并确保过时的内容不会被保留。
缓存控制头
并行连接与持续连接相结合，是今天解决网络延迟最小化的答案。
现在我们已经了解了缓存如何工作，现在是查看启用缓存基础架构的请求和响应头。保持内容清新和更新是缓存的主要职责之一。为了保持缓存的副本与服务器一致，HTTP提供了一些简单的机制，即文档过期和服务器重新验证。
文件到期
HTTP允许源服务器使用和响应头连接每个文档的到期日期。这有助于客户端和其他缓存服务器知道文档有效和新鲜的时间。只要文档的年龄在到期日期之内，缓存即可提供副本。一旦文档过期，缓存必须与服务器检查较新的副本，并相应地更新其本地副本。Cache-ControlExpires
Expires是一个旧的HTTP / 1.0响应头，将该值指定为绝对日期。这只有当服务器时钟与客户端同步时才有用，这是一个可怕的假设。与Cache-Control: max-age=<s>HTTP / 1.1中引入的较新的头文件相比，此标题不太有用。在这里，max-age是从创建响应时间开始的相对年龄（以秒为单位）。因此，如果文档在一天后过期，则过期标题应为Cache-Control: max-age=86400。
服务器重新验证
一旦缓存文档过期，缓存必须重新验证服务器，以检查文档是否已更改。这被称为服务器重新验证，并且用作文档陈旧的查询机制。只是因为缓存的副本已过期并不意味着服务器实际上具有较新的内容。重新验证只是确保缓存保持新鲜的方法。由于到期时间（如以前的服务器响应中所指定），缓存不需要与服务器检查每一个请求，从而节省带宽，缩短网络流量。
文档到期和服务器重新验证的组合是非常有效的机制，它允许分布式系统维护有效期的副本。
如果知道内容频繁更改，则可以减少到期时间 - 允许系统更频繁地重新同步。
重新验证步骤可以通过两种请求标头来实现：If-Modified-Since和If-None-Match。前者用于基于日期的验证，而后者使用实体标签（ETag），即内容的散列。这些标头使用从先前服务器响应获取的日期或ETag值。在情况下If-Modified-Since，使用Last-Modified响应头; 因为If-None-Match它是ETag响应头。
控制可达性
文档的有效期应由生成文档的服务器定义。如果是报纸网站，首页应该在一天之后过期（有时甚至每个小时！）。HTTP提供Cache-Control和Expires响应标头来设置文档的到期时间。如前所述，Expires是基于绝对日期，而不是用于控制缓存的可靠解决方案。
该Cache-Control标题是更为有用，有几个不同的价值观来约束客户应如何缓存响应：
- 缓存控制：无缓存：允许客户端存储文档; 但是，它必须在每个请求上重新验证服务器。有一个称为Pragma：no-cache的HTTP / 1.0兼容性头，其工作方式相同。
- 缓存控制：无存储：这是一个更强大的指令，客户端根本不存储文档。
- 缓存控制：必须重新验证：这将告诉客户端绕过其新鲜度计算，并始终使服务器重新生效。如果服务器不可用，则不允许提供缓存的响应。
- 缓存控制：max-age：设置从响应生成时起的相对过期时间（以秒为单位）。
另外，如果服务器没有发送任何Cache-Control标题，客户端可以自由使用自己的启发式到期算法来确定新鲜度。
限制客户的新鲜度
可访问性不仅限于服务器。也可以从客户端指定。这允许客户对它愿意接受的内容施加约束。这可以通过相同的Cache-Control标题，尽管有几个不同的值：
- 缓存控制：min-fresh = <s>：文档必须至少为ss秒以上。
- 缓存控制：MAX-陈旧或缓存控制：MAX-陈旧= <S> ：该文档不能从缓存中提供，如果它已经过时了长于<S>秒。
- 缓存控制：max-age = <s>：缓存不能返回缓存长于<s>秒的文档。
- Cache-Control：无缓存或Pragma：no-cache：除非已被重新验证，客户端将不会接受缓存的资源。
HTTP缓存实际上是一个非常有趣的话题，并且有一些非常复杂的算法来管理缓存的内容。要深入了解此主题，请参阅HTTP规范的缓存部分