通常使用的网络（包括互联网）是在TCP/IP协议族的基础上运作的。而HTTP属于它内部的一个子集。
把与互联网相关联的协议集合起来总称为TCP/IP。
TCP/IP协议族里重要的一点就是分层。TCP/IP协议族按层次分别分为以下4层：应用层、传输层、网络层和数据链路层。
应用层应用层决定了向用户提供应用服务时通信的活动。
TCP/IP协议族内预存了各类通用的应用服务。比如，FTP(File Transfer Protocol，文件传输协议)和DNS(Domain Name System，域名系统)服务就是其中两类。
HTTP协议也处于该层。
传输层传输层对上层应用层，提供处于网络连接中的两台计算机之间的数据传输。
在传输层有两个性质不同的协议：TCP(Transmission Control Protocol，传输控制协议)和UDP(User Data Protocol，用户数据报协议)。
网络层网络层用来处理在网络上流动的数据包。数据包是网络传输的最小数据单位。该层规定了通过怎样的路径（所谓的传输路线）到达对方计算机，并把数据包传送给对方。
链路层用来处理连接网络的硬件部分。硬件上的范畴均在链路层的作用范围之内。
发送端的客户端在应用层（HTTP协议）发出一个想看某个Web页面的HTTP请求。
接着，为了传输方便，在传输层（TCP协议）把从应用层处收到的数据（HTTP请求报文）进行分割，并在各个报文打上标记序号及端口号后转发给网络层。
在网络层（IP协议），增加作为通信目的地的MAC地址后转发给链路层。这样一来，发往网络的通信请求就准备齐全了。
接收端的服务器在链路层接收到数据，按序往上层发送，一直到应用层。当传输到应用层，才能算真正接收到由客户端发送过来的HTTP请求。
IP(Internet Protocol)网际协议位于网络层。几乎所有使用网络的系统都会用到IP协议。TCP/IP协议族中的IP指的就是网际协议。
IP协议的作用是把各种数据包传送给对方。而要保证确实传送到对方那里，则需要满足各类条件。其中两个重要的条件是IP地址和MAC地址(Media Access Control Address)。
IP地址指明了节点被分配到的地址，MAC地址是指网卡所属的固定地址。IP地址可以和MAC地址进行配对。IP地址可变换，但MAC地址基本上不会更改。
IP间的通信以来MAC地址。在网络上，通信的双方在同一局域网（LAN）内的情况是很少的，通常是经过多态计算机和网络设备中转才能连接到对方。而在进行中转时，会利用下一站中转设备的MAC地址来搜索下一个中转目标。这时，会采用ARP协议(Address REsolution Protocol)。ARP是一种用以解析地址的协议，根据通信方的IP地址就可以反查处对应的MAC地址。
在到达通信目标前的中转过程中，那些计算机和路由器等网络设备只能获悉很粗略的传输路线。这种机制成为路由选择(routing)。
TCP位于传输层，提供可靠的字节流服务。
所谓的字节流服务是指，为了传输方便，将大块数据分割成以报文段为单位的数据包进行管理。可靠的传输服务是指，能够把数据准确可靠地传给对方。
为了准确无误地将数据送达目标处，TCP协议采用了三次握手策略。
握手过程中使用了TCP的标志(flag)——SYN(synchronize)和ACK(acknowledgement)。
发送端首先发送一个带SYN标志的数据包给对方。接收端收到后，回传一个带有SYN/ACK标志的数据包以示传达确认信息。最后，发送端再回传一个带ACK标志的数据包，代表“握手”结束。
DNS(Domain Name System)服务是和HTTP协议一样位于应用层的协议。它提供域名到IP地址之间的解析服务。
DNS协议提供通过域名查找IP地址，或逆向从IP地址反查域名的服务。
URI(Uniform Resource Identifier)，URL(Uniform Resource Locator，统一资源定位符)，URL正是使用Web浏览器等访问Web页面时需要输入的网页地址。
URI用字符串标识某一互联网资源，而URL表示资源的地点（互联网上所处的位置）。可见URL是URI的子集。
URI格式：
URI格式构成简单理解就是由三部分组成：协议类型、服务器地址（和端口号）、路径
协议类型://服务器地址[:端⼝号]/路径 http://www.example.com/users?gender=male肯定是先从客户端开始建立通信的，服务端在没有接收到请求之前不会发送响应。
无论是请求报文还是响应报文，基本都由三部分组成：请求行【请求报文】（状态行【响应报文】）、Headers、Body
HTTP/1.1虽然是无状态协议，但为了实现期望的保持状态功能，于是引入了Cookie技术。
在说明HTTP提供的方法前，先说一下 REST 这个概念。
在网上有很多关于REST的介绍，事实上REST没有统一的答案，REST其实就是正确的使用HTTP的一种规范，即：
使用资源的格式来定义URL
规范地使用method来定义网络请求操作
规范地使用status code来表示响应状态
其他符合HTTP规范的设计准则
GET方法用来请求访问已被URI识别的资源。指定的资源经服务器端解析后返回响应内容。也就是说，如果请求的资源是文本，那就保持原样返回；如果是像CGI(Common Getway Interface，通用网关接口)那样的程序，则返回经过执行后的输出结果。
GET方法简单理解：
用于获取资源
对服务器数据不进行修改
不发送Body
虽然用GET方法也可以传输实体的主体，但一般不用GET方法进行传输，而是用POST方法。虽说POST的功能与GET很相似，但POST的主要目的并不是获取响应的主体内容。
POST方法简单理解：
用于增加或修改资源
发送给服务器的内容写在Body里面
鉴于HTTP/1.1的PUT方法自身不带验证机制，任何人都可以上传文件，存在安全性问题，一次一般的Web网站不使用该方法。若配合Web应用程序的验证机制，或架构设计采用REST(Representational State Transfer，表征状态转移)标准的同类Web网站，就可能会开放使用PUT方法。
PUT方法简单理解：
用于修改资源
发送给服务器的内容写在Body里面
HEAD方法和GET方法一样，只是不返回报文主体部分。用于确认URI的有效性及资源更新的日期时间等。
HEAD方法简单理解：
和GET使用方法完全相同
和GET唯一的区别在于，返回的响应中没有Body
DELETE方法用来删除文件，是与PUT相反的方法。DELETE方法按请求URI删除指定的资源。
HTTP/1.1的DELETE方法本身和PUT方法一样不带验证机制，所以一般的Web网站也不使用DELETE方法。当配合Web应用程序的验证机制，或遵守REST标准时还是有可能会开放使用的。
DELETE方法简单理解：
用于删除资源
不发送Body
上述的每次HTTP通信都需要经过三次握手连接和四次挥手断开，频繁通信是非常耗费资源的。
为解决上述TCP连接的问题，HTTP/1.1和一部分的HTTP/1.0想出了持久连接(HTTP Persistent Connections，也称为HTTP keep-alive或HTTp connection reuse)的方法。持久连接的特点是，只要任意一端没有明确提出断开连接，则保持TCP连接状态。
在HTTP/1.1中，所有的连接默认都是持久连接，但在HTTP/1.0内并未标准化。
持久连接使得多数请求以管线化方式发送成为可能。从前发送请求后需等待并收到响应，才能发送下一个请求。管线化技术出现后，不用等待响应亦可直接发送下一个请求。
保留无状态协议这个特征的同时又要解决类似的矛盾问题，于是引入了Cookie技术。Cookie技术通过在请求和响应报文中写入Cookie信息来控制客户端的状态。
Cookie会根据从服务器端发送的响应报文内的一个叫做Set-Cookie的首部字段信息，通知客户端保存Cookie。当下次客户端再往该服务器发送请求时，客户端会自动在请求报文中加入Cookie值后发送出去。
服务器端发现客户端发送过来的Cookie后，会去检查究竟是从哪一个客户端发来的连接请求，然后对比服务器上的记录，最后得到之前的状态信息。
用于HTTP协议交互的信息被称为HTTP报文。请求端（客户端）的HTTP报文叫做请求报文，响应端（服务器端）的叫做响应报文。HTTP报文本身是由多行（用CR+LF作换行符）数据构成的字符串文本。
HTTP报文大致可分为报文首部和报文主体两块。两者由最初出现的空行(CR+LF)来划分。通常，并不一定要有报文主体。
发送邮件时，我们可以在邮件里写入文字并添加多份附件。这是因为采用了MIME(Multipurpose Internet Mail Extensions，多用途因特网邮件扩展）机制，它允许邮件处理文本、图片、视频等多个不同类型的数据。
HTTP协议中也采纳了多部分对象集合，发送的一份报文主体内可含有多类型实体。通常是在图片或文本文件等上传时使用。
多部分对象集合包含的对象如下：
multipart/form-data
在Web表单文件上传时使用
multipart/byteranges
状态码206(Partial Content，部分内容)响应报文包含了多个范围的内容使用。
在HTTP报文中使用多部分对象集合时，需要在首部字段里加上Content-type。
如果下载过程中遇到网络中断的情况，那就必须重头开始。为了解决上述问题，需要一种可恢复的机制。所谓恢复是指能从之前下载中断处恢复下载。
要实现该功能需要指定下载的实体范围。像这样，指定范围发送的请求叫做范围请求。
首部字段Range来指定资源的byte范围。
响应会返回状态码为206 Partial Content的响应报文。另外，对于多重范围的范围请求，响应会在首部字段Content-type表明multipart/byteranges后返回响应报文；如果服务器端无法响应范围请求，则会返回状态码200 OK和完整的实体内容。
状态码简单理解：
类别原因1XX临时性消息。如：100 （继续发送）、101（正在切换协议）2XX成功。最典型的是 200（OK）、201（创建成功）3XX重定向。如 301（永久移动）、302（暂时移动）、304（内容未改变）4XX客户端错误。如 400（客户端请求错误）、401（认证失败）、403（被禁⽌）、404（找不到内容）5XX服务器错误。如 500（服务器内部错误）HTTP/1.1规范允许一台HTTP服务器搭建多个Web站点。
即使物理层只有一台服务器，但只要使用虚拟主机的功能，则可以假想已具有多台服务器。
如果一台服务器内托管了www.tricorder.jp和www.hackrjp这两个域名，当受到请求时就需要弄清楚究竟要访问哪个域名。
在相同的IP地址下，由于虚拟主机可以寄存多个不同主机名和域名的Web网站，因此在发送HTTP请求时，必须在Host首部内完整指定主机名或域名的URI。
代理、网关和隧道可以将请求转发给通信线路上的下一站服务器，并且能接收从那台服务器发送的响应再转发给客户端。
代理是一种有转发功能的应用程序，它扮演了位于服务器和客户端“中间人”的角色，接收由客户端发送的请求并转发给服务器，同时也接收服务器返回的响应并转发给客户端。
使用代理服务器的理由有：利用缓存技术减少网络带宽的流量，组织内部针对特定网站的访问控制，以获取访问日志为主要目的，等等。
代理按两种基准分类：一种是是否使用缓存，另一种是是否会修改报文。
代理转发响应时，缓存代理会预先将资源的副本（缓存）保存在代理服务器上。
当代理再次接收到相同资源的请求时，就可以不从源服务器那里获取资源，而是将之前缓存的资源作为响应返回。
转发请求或响应时，不对报文做任何加工的代理类型被称为透明代理。反之，对报文内容进行加工的代理被称为非透明代理。
网关是转发其他服务器通信数据的服务器，接收从客户端发送来的请求时，它就像自己拥有资源的服务器一样对请求进行处理。
利用网关能提高通信的安全性，因为可以在客户端与网关之间的通信线路上加密以确保连接的安全。
隧道是在相隔甚远的客户端和服务器两者之间进行中转，并保持双方通信连接的应用程序。
隧道可按要求建立起一条与其他服务器的通信线路，届时使用SSL等加密手段进行通信。隧道的目的是确保客户端能与服务器进行安全的通信。
隧道本身不会去解析HTTP请求。
缓存服务器是代理服务器的一种，并归类在缓存代理类型中。换句话说，当代理转发从服务器返回的响应时，代理服务器将会保存一份资源的副本。
缓存服务器的优势在于利用缓存可避免多次从源服务器转发资源。
即使存在缓存，也会因为客户端的要求、缓存的有效期等因素，向源服务器确认资源的有效性。若判断缓存失效，缓存服务器将会再次从源服务器上获取新资源。
浏览器缓存如果有效，就不必再向服务器请求相同的资源了，可以直接从本地磁盘内读取。
另外，和缓存服务器相同的一点是，当判定缓存过期后，会向源服务器确认资源的有效性。若判断浏览器缓存失效，浏览器会再次请求新资源。
Header 首部的作用是HTTP消息的metadata。
Host 指的是目标主机。这里需要注意，Host并不是在网络上用于寻址的，而是在目标服务器上用于定位子服务器的（比如一个网站 www.baidu.com，这个服务器下是有多个子服务器的）。
Content-Type 指定Body的类型。主要有四类：
text/html：请求Web页面是返回响应的类型，Body中返回html文本。格式如下： HTTP/1.1 200 OK Content-Type: text/html; charset=utf-8 Content-Length: 853 <!DOCTYPE html> <html> <head> <meta charset="utf-8"> .... x-www-form-urlencoded：Web页面纯文本表单的提交方式。格式如下：
POST /users HTTP/1.1 Host: api.github.com Content-Type: application/x-www-form-urlencoded Content-Length: 27 name=example&gender=male Retrofit的代码： @FormUrlEncoded @POST("/users") Call<User> addUser(@Field("name") String name, @Field("gender") String gender); multipart/form-data：Web页面含有二进制文件时提交方式。格式如下：
POST /users/ HTTP/1.1 Host: example.com Content-Type: multipart/form-data; boundary=--- WebkitFormBoundary7MA4YWxkTrZu0gW Content-Length: 2382 ------WebkitFormBoundary7MA4YWxkTrZu0gW Content-Disposition: form-data; name="name" vincent ------WebkitFormBoundary7MA4YWxkTrZu0gW Content-Disposition: form-data; name="avatar"; filename="avatar.jpg" Content-Type: image/jpeg JFIFHHv0w9jximQrWa...... ------WebkitFormBoundary7MA4YWxkTrZu0gW Retrofit的代码： @Multipart @POST("/users") Call<User> addUser(@Part("name") RequestBody name, @Part("avatar") RequestBody avatar); ... RequestBody namePart = RequestBody.create(MediaType.parse("text/plain"), nameStr); RequestBody avatarPart = RequestBody.create(MediaType.parse("image/jpeg"), avatarFile); api.addUser(namePart, avatarPart); application/json, image/jpeg, application/zip…：单项内容（文本或非文本都可以），用于Web Api的响应或者POST/PUT的请求。 请求提交json POST /users HTTP/1.1 Host: example.com Content-Type: application/json; charset=utf-8 Content-Length: 38 {"name:"vincent", "gender":"male"} Retrofit代码： @POST("/users") Call<User> addUser(@Body("user") User user); 响应返回json HTTP/1.1 200 OK content-type: application/json; charset=utf-8 content-length: 234 [{"login":"vincent", "id":1, "node_id":"xxxxx", "avatar_url":"https://avaars.githubusercontent.com/u/1?v=4", .....}] ----------------------------------------------------------------------- 请求提交二进制内容 POST /user/1/avatar HTTP/1.1 Host: example.com Content-Type: image/jpeg Content-Length: 1575 JFIFHH9....... Retrofit代码： @POST("user/{id}/avatar") Call<User> updateAvatar(@Path("id") String id, @Body RequestBody avatar); RequestBody avatarBody = RequestBody.create(MediaType.parse("image/jpeg", avatarFile); api.updateAvatar(id, avatarBody); 响应返回二进制内容 HTTP/1.1 200 OK content-type: image/jpeg content-length: 1575 JFIFHH9....Content-Length 指定Body的长度（字节）。
用于当响应发起时，内容长度还没能确定的情况下。和 Content-Length 不同时使用。用于是尽早给出响应，减少用户等待。
格式如下：
HTTP/1.1 200 OK Content-Type: text/html Transfer-Encoding: chunked 4 Chun 9 ked Trans 12 fer Encoding 0Location 指定重定向的目标URL。
用户代理，即是谁实际发送请求、接受响应的，例如手机浏览器、某款手机App。
Range/Accept-Range 能按范围请求数据。
Accept-Range: bytes 响应报文中出现，表示服务器支持按字节来取范围数据
Range: bytes=<start>-<end> 请求报文中出现，表示要取哪段数据。start和end指定取得字节范围
Content-Range:<start>-<end>/total 响应报文中出现，表示发送的是哪段数据
作用：常用于断点继传、多线程下载
Accept：客户端能接受的数据类型。如 text/html
Accept-Charset：客户端接受的字符集。如 utf-8
Accept-Encoding：客户端接受的压缩编码类型。如 gzip
Content-Encoding：压缩类型。如 gzip
HTTP主要有这些不足，举例如下：
通信使用明文（不加密），内容可能会被窃听
不验证通信方的身份，因此有可能遭遇伪装
无法证明报文的完整性，所以有可能已遭篡改
TCP/IP是可能被窃听的网络，按TCP/IP协议族的工作机制，通信内容在所有的通信线路上都有可能遭到窥视。
窃听相同段上的通信并非难事。只需要收集在互联网上流动的数据包（帧）就行了。对于收集来的数据包解析工作，可交给那些抓包或嗅探器工具。（所谓的抓包就是抓取没有通过SSL加密的在IP协议传输的报文段，抓到报文数据端后再解析出来）
用SSL建立安全通信线路之后，就可以在这条线路上进行HTTP通信了。与SSL组合使用的HTTP被称为HTTPS。
由于HTTP协议中没有加密机制，那么就对HTTP协议传输的内容本身加密。即把HTTP报文里所含的内容进行加密处理。由于该方式不同于SSL或TLS将整个通信线路加密处理，所以内容仍有被篡改的风险。
添加了加密及认证机制的HTTP称为HTTPS(HTTP Secure)。
HTTPS并非是应用层的一种新协议。只是HTTP通信接口部分用SSL(Secure Socket Layer)和TLS(Transport Layer Security)协议代替而已。
在详细介绍怎么使用HTTPS通信之前，有必要先了解在HTTPS中使用的加密技术：对称加密和非对称加密。
对称加密 就是通信双方完全使用同一个密钥，使用加密算法配合上密钥来加密，解密时使用加密过程的完全逆过程配合密钥来进行解密（即通信双方密钥相同，加密和解密算法不同）。
经典的算法：
DES（56位密钥，密钥太短而逐渐被弃用）
AES（128位、192位、256位密钥，现在最流行）
对称加密的作用：加密通信，防止信息在不安全网络上被截获后，信息被人读取或篡改
对称加密（如AES）的破解思路：
拿到一组或多组原文-密文对
设法找到一个密钥，这个密钥可以将这些原文-密文中的原文加密为密文，以及将密文解密为原文的组合，即为成功破解
反破解：一种优秀的对称加密算法的标准是，让破解者找不到比穷举法（暴力破解法）更有效的破解手段，并且穷举法的破解时间足够长（例如数千年）
对称加密的缺点：密钥泄露，不能在不安全网络上传输密钥，一旦密钥泄露则加密通信失败
非对称加密 就是发送端使用接收端提供的公钥对数据进行加密得到密文；服务端使用私钥将客户端使用公钥加密的密文解密得到原数据（即发送端持有公钥加密，接收端持有私钥解密，加解密算法相同，密钥不同）。
使用非对称加密通信，可以在不可信网络上将双方的公钥传给对方，然后再发消息前分别对消息使用对方的公钥来加密和使用自己的私钥来签名，做到不可信网络上的可靠密钥传播及加密通信。
由于私钥和公钥互相可解，因此非对称加密还可以应用于数字签名技术。
通常会对原数据hash以后对hash签名，然后附加在原数据后面作为签名。这是为了让数据更小。
经典算法：
RSA（可用于加密和签名）
DSA（仅用于签名，但速度更快）
非对称加密的优缺点：
优点：可以在不安全网络上传输密钥
缺点：计算复杂，因此性能相比对称加密差很多
非对称加密的破解：
和对称加密不同之处在于，非对称加密的公钥很容易获得，因此制造原文-密文对是没有困难的事
所以，非对称加密的关键在于，如何找到一个正确的私钥，可以解密所有经过公钥加密过的密文。找到这样的私钥即为成功破解
由于非对称加密的自身特性，怎样通过公钥推断出私钥通常是一种思路，但往往最佳手段依然是穷举法，只是和对称加密破解的区别在于，对称加密破解是不断尝试自己的新密钥是否可以将自己拿到的原文-密文对进行加密和解密，而非对称加密时不断尝试自己的新私钥是否和公钥互相可解
反破解：和对称加密一样，非对称加密算法优秀的标准同样在于，让破解者找不到比穷举法更有效的破解手段，并且穷举法的破解时间足够长
SSL采用一种叫做公开密钥加密的加密处理方式。
以对称加密的方式加密时必须将密钥也发送给对方。可究竟怎样才能安全地转交？在互联网上转发密钥时，如果通信被监听那么密钥就可能会落入攻击者之手，同时也就失去了加密的意义。另外还得设法安全地保管接收到的密钥。
非对称加密的方式很好的解决了对称加密的困难。
公开密钥加密使用一对非对称的密钥。一把叫做私有密钥，另一把叫做公开密钥。顾名思义，私有密钥不能让其他任何人知道，而公开密钥则可以随意发布，任何人都可以获得。
使用公开密钥加密方式，发送密文的一方使用对方的公开密钥进行加密处理，对方收到被加密的信息后，再使用自己的私有密钥进行解密。利用这种方式，不需要发送用来解密的私有密钥，也不用担心密钥被攻击者窃听而盗走。
HTTPS采用对称加密和非对称加密两者并用的混合加密机制。
在交换密钥环节使用公开密钥加密方式，之后的简历通信交换报文阶段则使用共享密钥加密方式。
数字证书认证机构的业务流程：首先，服务器的运营人员向数字证书认证机构提出公开密钥的申请。数字证书认证机构在判明提出申请者的身份之后，会对已申请的公开密钥做数字签名，然后分配这个已签名的公开密钥，并将该公开密钥放入公钥证书后绑定在一起。
服务器会将这份由数字证书认证机构颁发的公钥证书发送给客户端，以进行公开密钥加密方式通信。公钥证书也可叫做数字证书或直接称为证书。
接到证书的客户端可使用数字证书认证机构的公开密钥，对那张证书上的数字签名进行验证，一旦验证通过，客户端便可明确两件事：一，认证服务器的公开密钥的是真实有效的数字证书认证机构。二，服务器的公开密钥是值得信赖的。
此处认证机关的公开密钥必须安全地转交给客户端。使用通信方式时，如何安全转交是一件很困难的事，因此，多数浏览器开发商发布版本时，会事先在内部植入常用认证机关的公开密钥。
证书的一个作用是用来证明作为通信一方的服务器是否规范，另外一个作用是可确认对方服务器背后运营的企业是否真实存在。拥有该特性的证书就是EV SSL证书。
持有EV SSL证书的Web网站的浏览器地址栏处的背景是绿色的。
HTTPS中还可以使用客户端证书。以客户端证书进行客户端认证，证明服务器正在通信的对方始终是预料之内的客户端，其作用跟服务器证书如出一辙。
现状是，安全性极高的认证机构可颁发客户端证书但仅用于特殊用途的业务。例如，银行的网上银行就采用了客户端证书。在登陆网银时不仅要求用户确认输入ID和密码，还会要求用户的客户端证书，以确认用户是否从特定的终端访问网银。
先对上面的HTTPS建立通信的过程做一个简单通俗的总结：
Client Hello（Client：我们确认一下要用哪种SSL版本和加密组件）
Server Hello（Server：我们用xxxSSL版本和加密组件）
server发送服务器证书，信任建立（Server：给你公开密钥证书。【这个公开密钥是使用数字认证机构的私钥加密过的，而公开密钥已经提前植入到客户端，所以这一步是用客户端植入的公开密钥 数字验证 这个用数字认证机构私钥加密过的公开密钥 的真实性】）
Server Hello Done（Server：就先这样）
Pre-master Secret（Client：给你Pre-master Secret。【Pre-master Secret是使用服务端刚发送的公开密钥加密的随机密码串】）
客户端通知：将使用加密通信（Client：用我给你的Pre-master Secret加密通信）
客户端发送：Finished（Client：等你发给我确认对不对。【服务端会用自己的私钥解密Pre-master Secret】）
服务器通知：将使用加密通信（Server：给你发我的Pre-master Secret，你也用这个和我通信）
服务器发送：Finished（Server：那就这样确认SSL连接）
上面的所有步骤完成SSL连接，可以开始HTTP通信
下面是HTTPS建立通信的详细步骤：
步骤1：客户端通过发送Client Hello报文开始SSL通信。报文中包含客户端支持的SSL的指定版本、加密组件(Cipher Suite)列表（所使用的加密算法及密钥长度等）。
步骤2：服务器进行SSL通信时，会以Server Hello报文作为应答。和客户端一样，在报文中包含SSL版本以及加密组件。服务器的加密组件内容是从接收到的客户端加密组件内筛选出来的。
步骤3：之后服务器发送Certificate报文。报文中包含公开密钥证书。
步骤4：最后服务器发送Server Hello Done报文通知客户端，最初阶段的SSL握手协商部分结束。
步骤5：SSL第一次握手结束之后，客户端以Client Key Exchange报文作为回应。报文中包含通信加密中使用的一种被称为Pre-master secret的随机密码串。该报文已用步骤3中的公开密钥进行加密。
步骤6：接着客户端继续发送Change Cipher Spec报文。该报文会提示服务器，在此报文之后的通信会采用Pre-master secret密钥加密。
步骤7：客户端发送Finished报文。该报文包含连接至今全部报文的整体校验值。这次握手协商是否能够成功，要以服务器是否能够正确解密该报文作为协定标准。
步骤8：服务器同样发送Change Cipher Spec报文。
步骤9：服务器同样发送Finished报文。
步骤10：服务器和客户端的Finished报文交换完毕之后，SSL连接就算建立完成。当然，通信会受到SSL的保护。从此处开始进行应用层协议的通信，即发送HTTP请求。
步骤11：应用层协议通信，即发送HTTP响应。
步骤12：最后由客户端断开连接。断开连接时，发送close_notify报文。
在以上流程中，应用层发送数据时会附加一种叫做MAC(Message Authentication Code)的报文摘要。MAC能够查知报文是否遭到篡改，从而保护报文的完整性。
HTTP使用SSL(Secure Socket Layer)和TLS(Transport Layer Security)这两个协议。
TLS是以SSL为原型开发的协议，有时会统一称该协议为SSL。
为什么不一直使用HTTPS？
既然HTTPS那么安全可靠，那为何所有的Web网站不一直使用HTTPS？因为与纯文本通信相比，加密通信会消耗更多的CPU及内存资源。如果每次通信都加密，会消耗相当多的资源，平摊到一台计算机上时，能够处理的请求数量必定也会随之减少。因此，如果非敏感信息则使用HTTP通信，只有在包含个人信息等敏感数据时，才利用HTTPS加密通信。除此之外，想要节约购买证书的开销也是原因之一。
