**超文本传输协议（HTTP，HyperText Transfer Protocol）**主要是为Web浏览器与Web服务器之间的通信而设计的。当我们使用浏览器浏览网页的时候，我们网页就是通过HTTP请求进行加载的。HTTP协议是基于TCP协议，发送HTTP请求之前要先建立TCP连接也就是要经历3次握手。目前使用的HTTP协议大部分都是1.1.在1.1的协议里面，默认是开启了Keep-Alive的，这样的话建立的连接就可以在多次请求中被复用了。
另外，HTTP协议是“无状态”的协议，它无法记录客户端用户的状态，一般我们都是通过Session来记录客户端用户的状态。
**简单邮件传输 （发送）协议（SMTP，Simple Mail Transfer Protocol）**基于TCP协议，用来发送电子邮件。
注意：接收邮件的协议不是SMTP而是POP3协议。SMTP协议设计的内容较多，下面连两个比较重要：
比如我的邮箱是“[email protected]”，我要向“[email protected]”发送邮件，整个过程分为以下几步：
- 通过SMTP协议，我将写好的邮件交给163邮箱服务器（邮局）。
- 163服务器发现发送的邮箱是qq邮箱，然后使用SMTP协议将我的右键转发到qq邮箱服务器。
- qq邮箱服务器接收邮件之后就通知邮箱为“[email protected]”的用户来接受右键，然后用户就通过POP3/IMAP协议将邮件取出。
很多场景（比如邮件营销）下面我们需要判断我们要发送的邮箱地址是否真的存在，这个时候我们需要利用SMTP协议来检测。
只需要了解POP3和IMAP两者都是负责邮件接收的协议即可。SMTP协议只负责右键的发送，真正负责接收的协议是POP3/IMAP。
IMAP协议相比于POP3更新一点，为用户提供的可选功能也更多一点，几乎所有现代电子邮件客户端和服务端都支持IMAP。大部分网络邮件服务提供商都支持POP3和IMAP。
FTP协议主要提供文件传输服务，基于TCP实现可靠的传输。使用FTP传输文件的好处就是可以屏蔽操作系统和文件存储方式。FTP是基于客户-服务器（C/S）模型而设计的，在客户端与FTP服务器之间简历两个连接。如果我们要基于FTP协议开发一个文件传输的软件的话，首先要搞清楚出FTP的远离了。关于FTP的原理：
FTP的独特的优势同时也是与其他客户服务器程序最大的不同点就在于它在两台通信的主机之间使用了两条TCP连接（其他客户服务应用程序一般只有一条TCP连接）：
- 控制连接：用于传送控制信息（命令和响应）
- 数据连接：用于数据传送。
Telnet协议通过一个终端登录到其他服务器，建立在可靠的传输协议TCP之上。Telnet协议的最大缺点之一是所有数据（包括用户名和密码）均以明文形式发送，这有潜在的安全风险。这就是为什么如今很少使用Telnet并被一种称为SSH的非常安全的协议所取代的主要原因。
**SSH（Secure Shell）**是目前较可靠，专为远程登录绘画和其他网络服务提供安全性的协议。利用SSH协议可以有效防止远程管理过程中的信息泄露问题。SSH建立在可靠的传输协议TCP之上。
Telnet和SSH之间的主要区别在于SSH协议会对传输的数据进行加密保证数据安全性。
HTTP协议，全称超文本传输协议（Hypertext Transfer Protocol）。顾名思义，HTTP协议就是用来规范超文本的传输，超文本，也就是网络上的包括文本在内的各式各样的消息，具体来说，主要是为了规范浏览器和服务器端的行为的。
并且，HTTP是一个无状态协议，也就是说服务器不会维护任何有关客户端过去所发请求的消息。这其实是一种懒政，有状态协议会更加复杂，需要维护状态（历史信息），而且如果客户或服务器失效，会产生状态的不一致，解决这种不一致的代价更高。
HTTP是应用层协议，它以TCP（传输层）作为底层协议，默认端口为80.通信过程主要如下：
- 服务器在80端口等待客户的请求。
- 浏览器发起到服务器的
TCP连接（创建套接字Socket）。 - 服务器接收来自浏览器的
TCP连接。 - 浏览器（HTTP客户端）与Web服务器（HTTP服务器）交换HTTP消息。
- 关闭TCP连接。
HTTPS协议（Hyper Text Transfer Protocol Secure），是HTTP的加强安全版本。HTTPS是基于HTTP的，也是用TCP作为底层协议，并额外使用SSL/TLS协议用作加密和安全认证。默认端口是443。HTTPS协议中，SSL通道通常使用基于密钥的加密算法，密钥长度通常是40比特或128比特。
HTTPS之所以能达到较高的安全性要求，就是结合了SSL/TLS和TCP协议，对通信数据进行加密，解决了HTTP数据透明的问题。
SSL嘿人TLS没有太大的区别。
SSL值安全套接字协议（Secure Sockets Layer），首次发布于1996年。在1999年，SSL升级，**新版本被命名为TLS1.0。**因此，TLS是基于SSL之上的，但由于习惯叫法，通常把HTTPS中的核心加密协议混称为SSL/TLS。
SSL/TLS的核心要素是非对称加密。非对称加密采用两个密钥-一个公钥，一个四幺。在通信时，私钥仅由揭密折保存，公钥由任何一个想与解密者通信的发送者（加密者）所知。
非对称加密的公钥和私钥需要采用一种复杂的数学机制生成（密码学认为，为了较高的安全性，尽量不要自己创造加密方案）。公私钥对的生成算法依赖于单项陷门函数。
使用SSL/TLS进行通信的双方需要使用非对称加密方案来通信，但是非对称加密设计了较为复杂的数学算法，在实际通信过程中，计算的代价较高，效率太低，因此，SSL/TLS实际对消息的加密使用的是对称加密。
对称加密：通信双方共享唯一密钥k，加解密算法已知，加密方利用密钥k加密，解密方利用密钥k解密，保密性依赖于密钥k的保密性。
对称加密的密钥生成代价比公私钥对的生成代价低得多，为什么SSL/TLS还需要使用非对称加密呢？因为对称加密的保密性完全依赖于密钥的保密性。在双方通信之前，需要商量一个用于对称加密的密钥。我们知道网络通信的信道是不安全的，传输报文对任何人是可见的，密钥的交换肯定不能直接在网络信道中传输。因此，使用非对称加密，对对称加密的密钥进行加密，保护该密钥不在网络信道中被窃听。这样，通信双方只需要一次非对称加密，交换对称加密的密钥，在之后的信息通道中，使用绝对安全的密钥，对信息进行对称加密，即可保证传输消息的保密性。
在通道中传输时，可能会出现攻击者。这时候就出现一个信赖问题。
为了公钥传输的信赖性，第三方机构应运而生-证书颁发机构（CA，Certificate Authority）。CA默认是收信人的第三方。CA会给各个服务器颁发证书，证书存储在服务器上，并附有CA的电子签名。
当客户端（浏览器）向服务器发送HTTPS请求，一定要先获取目标服务器的证书，并根据证书上的信息，检验证书的合法性。一旦客户端检测到证书非法，就会发生错误。客户端获取了服务器的证书后，由于证书的新人行是由第三方信赖机构认证的，而证书上又包含着服务器的公钥信息，客户端就可以放心的信任证书上的公钥就是目标服务器的公钥。
数字签名要解决的问题，是防止证书被伪造。第三方信赖机构CA之所以能被信赖，就是靠数字签名技术。
数字签名：是CA再给服务器颁发证书时，使用散列 + 加密的组合技术，在证书上盖个章，以此来提供验伪的功能。具体行为如下：
CA知道服务器的公钥，对证书采用散列技术生成一个摘要。CA使用CA私钥对该摘要进行加密，并附在证书下方，发送给服务器。
现在服务器将该证书发送给客户端，客户端需要去验证该证书的身份。客户端找到第三方机构CA，获知CA的公钥，并用CA公钥对证书的签名进行解密，获得了CA生成的摘要。
客户端对证书数据（包含服务器的公钥）做相同的散列处理，得到摘要，并将该摘要与之前从签名中解码出的摘要做对比，如果相同，则身份验证成功；否则验证失败。
总结来说，带有证书的公钥传输机制如下：
- 设有服务器S，客户端C，和第三方信赖机构CA。
- S信任CA，CA知道S的公钥，CA向S颁发证书。并附上CA私钥对消息摘要的加密签名。
- S获得CA办法的证书，将该证书传递给C。
- C获得S的证书，信任CA并知晓CA公钥，使用CA公钥对S证书上的签名解密，同时对消息进行散列处理，得到摘要。比较摘要，验证S证书的真实性。
- 如果C验证S证书是真实的，则信任S的公钥（在S整数中）。
- 端口号：HTTP默认是80，HTTPS默认是443.
- URL前缀，HTTP前缀是
http://，HTTPS的前缀是https:// - 安全性和资源消耗：HTTP协议运行在TCP之上，所有传输的内容都是明文，客户端和服务器端都无法验证对方的身份。HTTPS是运行在SSL/TLS之上的HTTP协议，SSL/TLS运行在TCP之上。所有运输的内容都经过加密，加密采用对称加密，但对称加密的密钥用服务器方的证书进行了非对称加密。所以说，HTTP安全性没有HTTPS高，但是HTTPS比HTTP耗费更多服务器资源。
HTTP1.0仅定义了16中状态码。HTTP1.1中新加入了大量的状态码，光是错误相应状态码就新增了24种。比如说，100（Continue）-在请求打字员前的预热请求，206（Partial Content）-范围请求的标识码，409（Conflict）-请求与当前资源的规定冲突，410（Gone）-资源被永久转移，而且没有任何已知的转发地址。
缓存技术通过避免用户与源服务器的频繁交互，节约了大量的网络宽带，降低了用户信息的延迟。
HTTP1.0提供的缓存机制非常简单。服务器端使用Expires标签来标志（时间）一个响应体，在Expires标志时间内的请求，都会获得该响应体缓存。服务器端在初次返回给客户端的响应体中，有一个Last-Modified标签，该标签标记了被请求资源在服务器端的最后一次更改。在请求头中，使用If-Modified-Since标签，该标签标志一个时间，意为客户端向服务器进行问询：“该时间之后，我要请求的资源是否被修改过？”通常情况下，请求头中的If-Modified-Since的值即为上一次获得该资源时，响应体中的Last-Modified的值。
如果服务器接收到了请求头，并判断If-Modified-Since时间后，资源确实没有修改过，则返回给客户端一个304 not modified响应头，表示“缓冲可用，你从浏览器中拿吧！”
如果服务器判断If-Modified-Since时间后，资源被修改过，则返回给客户端一个200 OK的响应体，并附带全新的资源内容，表示“你要的我已经修改了，给你一份新的”
HTTP/1.1的缓存机制在HTTP/1.0的基础上，大大增加了灵活性和扩展性。基本工作原理和HTTP/1.0保持不变，而是增加了更多细致的特性。其中，请求头中最常见的特性就是Cache-Control
**HTTP1.0默认使用短链接，**也就是说，客户端和服务器没进行一次HTTP操作，就建立一次连接，任务结束就中断连接。当客户端浏览器访问的某个HTML或其他类型的Web页中包含有其他的Web资源（Javascript，CSS，图像等），每遇到这样一个Web资源，浏览器就会重新建立一个TCP连接，这样就会导致有大量的“握手报文”和“挥手报文”占用了带宽。
**为了解决HTTP1.0存在的资源浪费的问题，HTTP1.1优化为默认长连接模式。**采用长连接模式的请求报文会通知服务端：”我想你请求连接，并且连接成功建立后，请不要关闭“。因此，该TCP连接将持续打开，为后续的客户端-服务器端的数据交互服务。也就是说使用长连接的情况下，当一个网页打开完成后，客户端和服务器之间用于传输HTTP数据的TCP连接不会关闭，客户端再次访问这个服务器时，会继续使用这一条已经建立的连接。
如果TCP连接一直保持的话也是对资源的浪费，因此，一些服务器软件（如Apache）还会支持超时限制的时间。在超时时间之内没有新的请求达到，TCP连接才会被关闭。
有必要说明：HTTP1.0仍提供了长连接选项，即在请求头中加入Connectiion:Keep-alive。同样的，在HTTP1.1中，如果不希望使用长连接选项，也可以在请求头中加入Connection:close，这样会通知服务器：不需要长连接，连接成功后即可关闭。
HTTP协议的长连接和短链接，实质上是TCP协议的长连接和短链接。
实现长连接需要客户端和服务端都支持长连接。
域名系统（DNS）允许多个主机名绑定到同一个IP地址，但是HTTP1.0并没有考虑这个问题，假设我们有一个资源URL是http://example.org/home.html，HTTP1.0的请求报文中，将会请求的是GET /home.html HTTP/1.0。也就是不会加入主机名。这样的报文送到服务器端，服务器是理解不了客户端想请求的真正网址。
因此，HTTP1.1在请求头中加入了Host字段。加入Host字段的报文头部将会是：
Get /home.html HTTP/1.0
Host: example.orgHTTP1.1引入了范围请求（range request）机制，以避免带宽的浪费。当客户端请求一个文件的一部分，或者需要继续下载一个已经下载了部分但被终止的文件，HTTP1.1可以在请求中加入Range头部，以请求（并只能请求字节型数据）数据的一部分。服务器端可以忽略Range头部，也可以返回若干Range响应。
如果一个相应包含部分数据的话，那么将带有206 Partial Content状态码。该状态码的意义在于避免了HTTP1.0代理缓存错误地把该响应认为是一个完整的数据响应，从而把它当作为一个请求的相应缓存。
在范围响应中，Content-Range头部标志指示出了该数据块的偏移量和数据块的长度。
HTTP1.1中新加入了状态码100.该状态码的使用场景为，存在某些较大的文件请求，服务器可能不愿意相应这种请求，此时状态码100可以作为指示请求是否会被正常相应。过程如下：
在HTTP1.0中，并没有100（Continue）状态码，要想触发这一机制，可以发送一个Expect头部，其中包含一个100-continue的值。
许多格式的数据在传输时都会进行预压缩处理。数据的压缩可以大幅优化带宽的利用。然而，HTTP1.0对数据压缩的选项提供的不多，不支持压缩细节的选择，也无法区分到端（end-to-end）压缩或者是逐跳（hop-by-hop）压缩。HTTP1.1则对内容编码（content-codings）和传输编码（transfer-codings）做了区分。内容编码总是端到端的，传输编码总是逐跳的。HTTP1.0包含了Content-Encdoing头部，对消息进行端到端编码。HTTP1.1加入了Transfer-Encoding头部，可以对消息进行逐跳传输编码。HTTP1.1还加入了Accept-Encoding头部，是客户端用来指示它能处理什么样的内容编码。
- 连接方式：
HTTP1.0为短链接，HTTP1.1支持长连接。 - 响应状态码：
HTTP1.0中新加入了大量的状态码，光是错误相应状态码就新增了24中。 - **缓存处理：**在
HTTP1.0中主要使用header里的If-Modified-Since，Expires来做为缓存判断的标准，HTTP1.1则引入了更多的缓存控制策略。 - 带宽优化及网络连接的使用：
HTTP1.0中，存在一些浪费带宽的现象。HTTP1.1则在请求头中引入了Range头域，这样就方便开发者自由的选择以便于充分利用带宽和连接。 - Host头处理：
HTTP1.1在请求头中加入了Host字段。
- 200 OK ：请求被成功处理。比如我们发送一个查询用户数据的HTTP 请求到服务端，服务端正确返回了用户数据。这个是我们平时最常见的一个 HTTP 状态码。
- 201 Created ：请求被成功处理并且在服务端创建了一个新的资源。比如我们通过 POST 请求创建一个新的用户。
- 202 Accepted ：服务端已经接收到了请求，但是还未处理。
- 204 No Content ： 服务端已经成功处理了请求，但是没有返回任何内容。
简单来说，204状态码描述的是我们向服务端发送HTTP请求之后，只关注处理结果是否成功的场景。也就是说我们只需要一个结果：true/false。
- 400 Bad Request ： 发送的HTTP请求存在问题。比如请求参数不合法、请求方法错误。
- 401 Unauthorized ： 未认证却请求需要认证之后才能访问的资源。
- 403 Forbidden ：直接拒绝HTTP请求，不处理。一般用来针对非法请求。
- 404 Not Found ： 你请求的资源未在服务端找到。比如你请求某个用户的信息，服务端并没有找到指定的用户。
- 409 Conflict ： 表示请求的资源与服务端当前的状态存在冲突，请求无法被处理。
- 500 Internal Server Error ： 服务端出问题了（通常是服务端出Bug了）。比如你服务端处理请求的时候突然抛出异常，但是异常并未在服务端被正确处理。
- 502 Bad Gateway ：我们的网关将请求转发到服务端，但是服务端返回的却是一个错误的响应。