网络通信协议
网络模型
网络分层是由硬件和软件模块来完成网络节点数据的一系列工作。常见的网络模型如：
- 因特网模型【五层】
应用层 → 运输层 → 网络层 → 链路层 → 物理层 - OSI/ISO模型【开放式系统互联 七层】
应用层 → 表示层 → 会话层 → 运输层 → 网络层 → 链路层 → 物理层 - 简化五层 → TCP/IP模型【最常见 四层】
应用层 → 运输层 → 网络层 → 网络接口层
TCP/IP 四层模型
TCP/IP 协议模型（Transmission Control Protocol/Internet Protocol），包含了一系列构成互联网基础的网络协议，是互联网相关的各类协议族的总称，而不是单指 TCP 协议或 IP 协议，是Internet的核心协议。
- 应用层：位于应用层要传递的信息称为报文，根据规则解析传输层发送过来的数据，并决定了向用户提供应用服务时通信的活动。FTP（文件传输），DNS（域名服务），HTTP（Web服务协议）。目前主要使用两种体系结构，C/S结构（客户端/服务端结构），P2P结构（对等体系结构）。
- 传输层：协议把应用层的报文封装成一个新的结构，叫做报文段，为两台主机上的应用程序提供端到端的通信。常见的有 TCP、UDP 协议。
- 网络层：把传输层的报文段封装成一个叫做数据报的数据结构，建立主机到主机的通信。该层决定如何将数据从发送方路由到接收方. 网络层通过综合考虑发送优先权,网络拥塞程度,服务质量以及可选路由的花费来决定从一个网络节点A到另一个网络节点B的最佳路径。常见的如 ip 协议。
- 网络接口层：对应数据链路层和物理层。
- 链路层：这一层把网络层的数据报再次封装，叫做帧。这一层把帧从当前节点移动到下一个节点，如从主机传输到路由器。主要功能是如何在不可靠的物理线路上进行数据的可靠传递，如果在传输数据时，接收点检测到所传数据中有差错，就要通知发送方重发这一帧。
- 物理层：该层负责比特流在节点间的传输，即负责物理传输，该层的协议既与链路有关，也与传输介质有关，通俗来讲就是把计算机链接起来的物理手段。
OSI 七层网络模型
为了使不同厂家生产的计算机可以相互通信，建立更大范围的计算机网络，国际标准化组织（ISO）在 1984 年提出了“开放系统互联参考模型”，即 OSI/RM 模型（Open System Interconnection/Reference Model）。
OSI 模型将计算机网络体系结构的通信协议划分为七层，每一层都建立在它的下层之上，同时向它的上一层提供一定服务。上层只管调用下层提供的服务，而不用关心具体实现细节，有些类似我们开发中对外暴露接口隐藏实现的思想。
七层模型自下而上分别为：物理层、数据链路层、网络层、传输层、会话层、表示层、应用层。其中低四层完成数据传输，高三层面向用户。
Http
HTTP 协议的主要特点
- 支持 C/S（客户/服务器）模式。
- 应用层；是一个属于应用层的面向对象的协议，常配合 TCP/IP 使用。
- 简单快速：
客户向服务器请求服务时，只需传送请求方法和路径。请求方法常用的有 GET、HEAD、POST，每种方法规定了客户与服务器联系的类型不同。由于HTTP协议简单，使得HTTP服务器的程序规模小，因而通信速度很快。 - 灵活：HTTP允许传输任意类型的数据对象。正在传输的类型由 Content-Type 加以标记。
- 无连接：
无连接的含义是限制每次连接只处理一个请求。服务器处理完客户的请求，并收到客户的应答后，即断开连接。采用这种方式可以节省传输时间。
由于HTTP在每次请求结束后都会主动释放连接，因此 HTTP 连接是一种“短连接”，要保持客户端程序的在线状态，需要不断地向服务器发起连接请求。通常 的做法是即时不需要获得任何数据，客户端也保持每隔一段固定的时间向服务器发送一次“保持连接”的请求，服务器在收到该请求后对客户端进行回复，表明知道 客户端“在线”。若服务器长时间无法收到客户端的请求，则认为客户端“下线”，若客户端长时间无法收到服务器的回复，则认为网络已经断开。 - 无状态：
HTTP 协议是无状态协议，无状态是指协议对于事务处理没有记忆能力。缺少状态意味着如果后续处理需要前面的信息，则它必须重传，这样可能导致每次连接传送的数据量增大。另一方面，在服务器不需要先前信息时它的应答就较快。当断开连接后，下次客户端向同样的服务端发送请求时，需重新建立连接。 - 请求与响应；
HTTP 连接最显著的特点是客户端发送的每次请求都需要服务器回送响应，在请求结束后，会主动释放连接。从建立连接到关闭连接的过程称为“一次连接”。- 在 HTTP 1.0中，客户端的每次请求都要求建立一次单独的连接，在处理完本次请求后，就自动释放连接。
- 在 HTTP 1.1中则可以在一次连接中处理多个请求，并且多个请求可以重叠进行，不需要等待一个请求结束后再发送下一个请求。
一次网络请求的过程是怎样的，简单的讲，为域名解析（将注册域名解析为 IP 地址）、TCP握手建立连接、客户端发起HTTP请求、服务器响应请求、客户端解析接收数据（客户端解析html代码，同时请求html代码中的资源）并渲染页面。
HTTP URL 的格式如下
1 | http://host[":"port][abs_path] |
http 表示要通过 HTTP 协议来定位网络资源；host 表示合法的 Internet 主机域名或者IP地址；port 指定一个端口号，为空则使用默认端口80；abs_path 指定请求资源的 URI（Web上任意的可用资源）。
DNS协议
位于应用层，提供域名到IP之间的解析服务。
DNS 协议解析（域名解析协议），用来实现域名和 IP 地址的转换。主要基于 UDP 实现，端口 53。域名是分层结构，是为了保证域名的唯一性。域名服务器分为（根，顶级，权限，本地）四种域名服务器。
IP 协议
IP 协议提供了主机和主机间的通信，为了完成不同主机的通信，我们需要某种方式来唯一标识一台主机，这个标识，就是著名的IP地址。通过IP地址，IP 协议就能够帮我们把一个数据包发送给对方。
所有的TCP，UDP，ICMP，IGCP的数据都以IP数据格式传输。要注意的是，IP不是可靠的协议，这是说，IP协议没有提供一种数据未传达以后的处理机制，这被认为是上层协议——TCP或UDP要做的事情。
IP协议使用ARP协议（ARP协议是用以解析地址的协议）凭借MAC地址进行通信。
TCP：传输控制协议
TCP 的全称是 Transmission Control Protocol。
TCP 协议在 IP 协议提供的主机间通信功能的基础上，完成两个主机上进程对进程的通信。
有了 IP，不同主机就能够交换数据。但是，计算机收到数据后，并不知道这个数据属于哪个进程（简单讲，进程就是一个正在运行的应用程序）。TCP 的作用就在于，让我们能够知道这个数据属于哪个进程，从而完成进程间的通信。
为了标识数据属于哪个进程，给需要进行 TCP 通信的进程分配一个唯一的数字来标识它。这个数字，就是端口号。
TCP具有面向连接的特性，之所以说它是有连接的，是因为在进行通信前，通信双方需要先经过一个三次握手的过程。三次握手完成后，连接便建立了。这时才可以开始发送/接收数据。（与之相对的是 UDP，不需要经过握手，就可以直接发送数据）。
TCP是面向字节流的传输方法。
提供可靠的字节流服务，确保可靠性。
TCP把应用程序看成是一连串的无结构的字节流，交互是一次一个大小不等的数据块。
字节流服务指将大块数据分割成以报文段为单位的数据包进行管理。
TCP有一个缓冲，当应用程序传送的数据块太长，TCP就把它划分短一些再传送。
如果应用程序一次只发送一个字节，TCP也可以等待积累足够多的字节再构成报文段发送出去。
使用三次握手确保数据能到达目的地。
TCP连接相关的报文相关缩写：SYN（同步标志synchronous）、ACK（确认标志Acknowledgement）、ACK序号（Acknowledgment Number）、SEQ（序列号Sequence Number）、FIN（结束标志final）。
TCP 三次握手
第一次握手，客户端发送 SYN 报文，SYN 值为 1，seq 值 为 x（这个 x 是由操作系统根据一定的规则生成的，不妨认为它是一个随机数。），并且客户端进入 SYN_SENT 状态，等待服务端响应。第二次握手，服务端接收到 SYN 报文，对其进行确认，并发送 SYN-ACK 报文，SYN 值为1，seq 值为 y，ACK 值为 x+1，并且服务端进入 SYN—RCVD 状态。第三次握手，客户端收到 SYN-ACK 报文段，并发送 ACK 报文段，ACK 值为 y+1，然后客户端和服务端进入 TCP 连接成功状态，完成三次握手。（注意：如果中途哪个环节中断了，则会重复发送相同的数据包，直到握手结束。）
当 TCP 连接建立成功。这里需要注意的有三点：
- 连接是由客户端主动发起的
- 在第 3 步客户端向服务器回复 ACK 的时候，TCP 协议是允许我们携带数据的。之所以做不到，是 API 的限制导致的。
- TCP 协议还允许 “四次握手” 的发生，同样的，由于 API 的限制，这个极端的情况并不会发生。
Tcp 四次挥手
第一次挥手，客户端发送 FIN 报文段，seq 值为 x+2，ACK 值为 y+1，并且客户端进入FIN_WAIT_1 状态，表示没有数据要发给服务端了。第二次挥手，服务端收到 FIN 报文段，并回了一个 ACK 报文段，ACK 值为 x+3，表示同意你的关闭请求。第三次挥手，服务端发送 FIN 报文段，seq 值为 y+1，请求关闭连接，同时服务端进入 LAST_ACK 状态。第四次挥手，客户端收到 FIN 报文段，并发送 ACK 报文段，ACK 值为 y+2，并且客户端进入 TIME_WAIT 状态。服务端收到 ACK 报文段后，就关闭连接。此时，客户端等待一段时间后（2MSL）依然没有收到回复，则说明服务端已正常关闭，这样客户端也可以关闭连接了。（注意：通常由客户端先发起挥手，但也可以是服务器端先发起）
为什么要进行三次握手?
三次握手不是 TCP 本身的要求, 而是为了满足”在不可靠信道上可靠地传输信息”这一需求所导致的.。
为什么不是两次而必须是三次?
三次握手完成两个重要的功能，既要双方做好发送数据的准备工作(双方都知道彼此已准备好)，也要允许双方就初始序列号进行协商，这个序列号在握手过程中被发送和确认。
现在把三次握手改成仅需要两次握手，死锁是可能发生的。作为例子，考虑计算机S和C之间的通信，假定C给S发送一个连接请求分组，S收到了这个分组，并发 送了确认应答分组。按照两次握手的协定，S认为连接已经成功地建立了，可以开始发送数据分组。可是，C在S的应答分组在传输中被丢失的情况下，将不知道S 是否已准备好，不知道S建立什么样的序列号，C甚至怀疑S是否收到自己的连接请求分组。在这种情况下，C认为连接还未建立成功，将忽略S发来的任何数据分 组，只等待连接确认应答分组。而S在发出的分组超时后，重复发送同样的分组。这样就形成了死锁。
挥手为什么是四次？
TCP 连接是全双工的，每一端都可以同时发送和接受数据，关闭的时候两端都要关闭各自两个方向的通道，总共相当于要关闭四个。
为什么 TIME_WAIT 状态需要经过 2MSL (最大报文段生存时间) 才能返回到 CLOSE 状态
首先，MSL（Maximum Segment Life），是 TCP 对 TCP Segment 生存时间的限制。
客户端在发出确认服务端关闭的 ACK 后，它没有办法知道对方是否收到这个消息，于是需要等待一段时间，如果服务端没有收到关闭的消息后会重新发出 FIN 报文，这样客户端就知道自己上条消息丢了，需要再发一次；如果等待的这段时间没有在收到 FIN 的重发报文，说明它的确已经收到断开的消息并且已经断开了。
这个等待时间至少是：客户端的 timeout + FIN 的传输时间，为了保证可靠，采用更加保守的等待时间 2MSL。
如果已经建立了连接，但是客户端突然出现故障了怎么办
TCP还设有一个保活计时器，显然，客户端如果出现故障，服务器不能一直等下去，白白浪费资源。服务器每收到一次客户端的请求后都会重新复位这个计时器，时间通常是设置为2小时，若两小时还没有收到客户端的任何数据，服务器就会发送一个探测报文段，以后每隔75秒钟发送一次。若一连发送10个探测报文仍然没反应，服务器就认为客户端出了故障，接着就关闭连接。
UDP：用户数据报协议
面向报文的传输方式。
应用层交给UDP多长的报文，UDP就照样发送，既不合并，也不分解，而是保留这些报文的边界，即一次发送一次报文。
因此，应用程序必须选择合适大小的报文，太长会导致IP层需要分片，降低效率，太短则会使IP太小。
区别
| TCP | UDP |
|---|---|
| 面向有连接的通信服务 | 面向无连接的通信服务 |
| 提供可靠的通信传输 | 不可靠，不能保证数据传输的完整性 |
| 保证数据顺序 | 不保证 |
| 传输的数据没有大小限制 | 传输数据有大小限制，每个被传输的数据限定在64KB之内 |
| 耗时较多开销较大 | 传输速度快开销较小 |
| 面向字节流 | 面向报文 |
| 只支持点对点的通信 | 支持一对一、一对多、多对一、多对多通信 |
| 报头至少20字节 | 报头8字节 |
| 有流量控制，拥塞控制 | 没有 |
URL和URI
- URI：统一资源标识符，用字符串标识某一互联网资源。
- URL：统一资源定位符，表示资源的地点，为URI的子集。
HTTP报文
用于 HTTP 协议交互的信息被称为 HTTP 报文。
HTTP 报文可以分为请求报文和响应报文：
- 请求端（客户端）的HTTP报文叫做请求报文：
请求报文主要分为四个部分，请求行、请求头、空行、请求体： - 起始行：请求行（请求方法，HTTP版本，URL）
- 首部：请求条件和属性的首部（请求首部字段，通用···，实体···，其他）
- 主体：报文主体（与首部之间会有一个空行）
- 示例：
1
2
3
4
5
6
7
8
9
10
11// 请求报文格式：
<method> <request-url> <version>
<headers>
<entity-body>
// 各个标签的含义
<method> 指请求方法，常用的主要是Get、 Post、Head 还有其他一些不常用的。
<version> 指协议版本，现在通常都是Http/1.1了
<request-url> 请求地址 - 响应端（服务器端）的HTTP报文叫做响应报文：
响应报文主要分为四个部分，状态行、响应头、空行、响应体： - 起始行：状态行（响应结束状态码，HTTP版本，短语）
- 首部：请求条件和属性的首部（响应首部字段，通用···，实体···，其他）
- 主体：报文主体（与首部之间会有一个空行）
- 示例：
1
2
3
4
5
6
7
8
9
10
11// 响应报文格式
<version> <status> <reason-phrase>
<headers>
<entity-body>
// 各个标签的含义
<version> 指协议版本，现在通常都是Http/1.1了
<status> 指响应状态码， 比如熟悉的200、404等等
<reason-phrase> 原因短语，200 OK 、404 Not Found 这种后面的描述就是原因短语，通常不必太关注。
method
PUT：传输文件
DELETE：删除文件
GET：表示请求获取 Request-URI 所标识的资源
POST：表示在 Request-URI 所标识的资源后附加新的数据
对于常用的Get和POST请求方法，两者的区别：
- 传输形式上有些区别：
通过Get方法发起请求时，会将请求参数拼接在request-url尾部，格式是url?param1=xxx¶m2=xxx&[…]，但参数都会暴露在地址栏中。
并且由于url是ASCII编码的，所以参数中如果有Unicode编码的字符，例如汉字，都会编码之后传输。
虽然http协议并没有对url长度做限制，但是一些浏览器和服务器可能会有限制，所以通过GET方法发起的请求参数不能够太长(不大于2KB)。
而通过POST方法发送的请求是将参数放在请求体中的，传输量一般无大小限制，所以不会有GET参数的这些问题。 - 方法本身的语义：
GET方法通常是指从服务器获取某个URL资源，其行为可以看作是一个读操作(查询操作，而且应该是安全和幂等的)，对同一个URL进行多次GET并不会对服务器产生什么影响。
而POST方法通常是对某个URL进行添加、修改，例如一个表单提交，通常会往服务器插入一条记录。多次POST请求可能导致服务器的数据库中添加了多条记录。 - 效率的区别：
Post执行效率低，Get执行效率略高。
因为Get将参数拼成URL,放到header消息头里传递。
Post直接以键值对的形式放到消息体中传递。
但两者的效率差距很小很小。
状态码
常见的状态码：
| 状态码 | 含义 |
|---|---|
| 1XX | Informational（信息性状态码） 接受的请求正在被处理 |
| 2XX | Success（成功状态码） 请求正常处理完毕 |
| 3XX | Redirection（重定向状态码） 需要进行附加操作以完成请求 |
| 4XX | Client Error（客户端错误状态码） 服务器无法处理请求 |
| 5XX | Server Error（服务器错误状态码） 服务器处理请求出错 |
| 200 OK | 请求成功，实体包含请求的资源 |
| 301 Moved Permanent | 请求的URL被移除了，通常会在Location首部中包含新的URL用于重定向。 |
| 304 Not Modified | 条件请求进行再验证，资源未改变。 |
| 404 Not Found | 资源不存在 |
| 206 Partial Content | 成功执行一个部分请求。这个在用于断点续传时会涉及到。 |
首部
首部字段是为了给浏览器和服务器提供报文主体，所使语言，认证信息等内容，它由首部字段名和字段值构成，中间用冒号“:”分割。
在请求报文和响应报文中都可以携带一些信息，通过与其他部分配合，能够实现各种强大的功能。
这些信息位于起始行之下与请求实体之间，以键值对的形式，称之为首部。
每条首部以回车换行符结尾，最后一个首部额外多一个换行，与实体分隔开。
首部类型：
- 通用首部字段：请求报文和响应报文均可以使用
- 请求首部字段：补充了请求的附加信息，客户端信息等。
- 响应首部字段：补充了响应的附加内容
- 实体首部字段：补充了资源内容更新时间等与实体有关的信息
一些常见的header：
| header | 含义 |
|---|---|
| Date | |
| Cache-Control | 控制缓存的行为 |
| Host | 请求资源所在服务器 |
| Content-Encoding | 实体主体适用的编码方式 |
| Content-Length | 实体主体的大小（单位：字节） |
| Content-Type | 实体主体的媒体类型 |
| Set-Cookie | 开始状态管理所使用的Cookie信息，为响应首部字段。 |
| Last-Modified | 服务器返回的响应首部。 |
| Etag | 服务器返回的响应首部。Etag首部实际上可以认为是服务器对文档资源定义的一个版本号。有时候一个文档被修改了，可能所做的修改极为微小，并不需要所有的缓存都重新下载数据。或者说某一个文档的修改周期极为频繁，以至于以秒为时间粒度的判断已经无法满足需求。这个时候可能就需要Etag这个首部来表明这个文档的版号了。 |
| Expires | |
| If-Modified-Since | 可结合Last-Modified使用，当发起条件请求时，将Last-Modified首部的值作为If-Modified-Since首部的值传递到服务器，意思是查询服务器的资源自从我们上一次缓存之后是否有修改。 |
| If-None-Match | 需结合另一个Etag使用。发起条件请求时可将缓存时保存下来的Etag的值作为If-None-Match首部的值发送至服务器，如果服务器的资源的Etag与当前条件请求的Etag一致，表明这次再验证命中。 |
| If-Unmodified-Since | 断点续传相关 |
| If-Range | 断点续传相关 |
| If-Match | 断点续传相关 |
实体
请求发送的资源，或是响应返回的资源。
Http缓存
缓存可以节约不必要的网络宽带，并且能迅速的对http请求做出响应。
当发起一个http请求后，可以将服务器返回的资源的副本存储在本地，这样当再次对该url资源发起请求时，可以快速的从本地存储设备中获取到该url资源，这就是所谓的缓存。
| 概念 | 含义 |
|---|---|
| 新鲜度检测 | 为了避免本地缓存的资源与服务器的资源有差异，所以当发起一个请求时，需要先对缓存的资源进行判断，是否未超过一定的时间并可以直接使用缓存资源，这个就叫做新鲜度检测。 |
| 再验证 | 若发现该缓存资源已经超过了一定的时间，当再次发起请求时不会直接将缓存资源返回，而是先去服务器查看该资源是否已经改变，这个就叫做再验证。 |
| 再验证命中 | 若服务器发现对应的url资源并没有发生变化，则会返回304 Not Modified，并且不再返回对应的实体。这称之为再验证命中。相反如果再验证未命中，则返回200 OK，并将改变后的url资源返回，此时缓存可以更新以待之后请求。 |
具体的实现方式：
- 新鲜度检测
由服务器通过在响应报文中增加Cache-Control:max-age（http1.1的协议规范，通常是接相对的时间，即多少秒以后，需要结合last-modified这个首部计算出绝对时间。），或是Expire（http1.0的规范，后面接一个绝对时间。）这两个首部来判断是否超过了一定的时间。 - 再验证
采用一种称之为“条件请求”的方式来实现验证，提供缓存资源给服务器判断是否一致。 - Http定义了5个首部用于条件请求：
- If-Modified-Since
- If-None-Match
- If-Unmodified-Since
- If-Range
- If-Match
HTTPS
使用HTTP协议的客户端，会打开一条服务端端口为80的连接，并发送老的HTTP请求。使用HTTPS协议的客户端，会打开一条服务端端口为443连接，然后与服务器进行SSL握手。以二进制格式与服务器交互一些SSL的安全参数，附上加密的HTTP请求。
传统的HTTP协议是一种应用层的传输协议，HTTP直接与TCP协议通信（HTTP → TCP → IP）。其本身存在一些缺点：
- HTTP使用明文传输，容易遭到窃听。HTTPS是SSL加密传输。
- 对于通信双方都没有进行身份验证，通信的双方无法确认对方是否是伪装的客户端或者服务端。
- 对于传输内容的完整性没有确认的办法，往往容易在传输过程中被劫持篡改。
而HTTPS就是身披SSL（一种网络安全技术）外壳的HTTP，HTTP是和TCP通信，而HTTPS则是先和SSL通信，再由SSL和TCP通信。（HTTP → SSL/TLS → TCP → IP）
HTTPS可以通过增加的SSL/TLS，支持对于通信内容的加密，以及对通信双方的身份进行验证。
简单地说：HTTP + 加密（保证密码） + 认证（验证通信方） + 完整性保护（报文的完整） = HTTPS
端口号是443
Https的加密
加密方式主要有两类：
- 对称秘钥加密（共享秘钥加密）：
指加密与解密过程使用同一把秘钥。
优点是处理速度快。
缺点是无法保证一方将秘钥传递到通信的另一方的安全，可能会在传输过程中被拦截。 - 非对称密钥加密（公开秘钥加密）：
指加密与解密使用两把不同的秘钥。
一把叫公开秘钥，可随意对外公开。
一把叫私有秘钥，只用于本身持有。
得到公开秘钥的客户端可以使用公开秘钥对传输内容进行加密，而只有私有秘钥持有者本身可以对公开秘钥加密的内容进行解密。
也就是发送方使用对方的公开秘钥进行加密，接收方用私有秘钥解密。
优点是克服了秘钥交换的问题，没有被拦截的风险。
缺点是相对于对称秘钥加密的方式，处理速度较慢。
而HTTPS采用混合加密机制：
SSL\TLS的加密方式则是结合了两种加密方式的优点。
首先采用非对称秘钥加密，将一个对称秘钥使用公开秘钥加密后传输到对方。
对方使用私有秘钥解密，得到传输的对称秘钥。
之后双方再使用对称秘钥进行通信。
也就是说，交换秘钥环节使用公开秘钥加密方式，交换报文阶段使用共享秘钥加密方式。
这样即解决了对称秘钥加密的秘钥传输问题，又利用了对称秘钥的高效率来进行通信内容的加密与解密。
Https的认证
为什么要认证：
- 公开秘钥方式无法证明公开秘钥本身就是货真价实的公开秘钥
- 公开秘钥在传输过程中可能被篡改
目前的做法是使用由数字证书认证机构（CA）和其相关机构颁发的公开秘钥证书。
加入数字证书认证的加密过程：
- 服务器的运营人员把自己的公开秘钥登陆至数字证书认证机构，向认证机构提出公开秘钥申请。
- 数字证书认证机构审核之后，用自己的私有秘钥向服务器的公开秘钥署数字签名并颁发公钥证书。
- 服务器就可以将这个公钥证书下发给客户端，客户端拿到服务器的公钥证书后，使用数字证书认证机构的公开秘钥，向数字证书认证机构验证公钥证书上的数字签名，以确认服务器的公开秘钥的真实性。
- 验证成功后，使用服务器的公开秘钥对报文加密后发送
- 服务器用私有秘钥对报文解密。
HTTPS的完整性保护
应用层使用HTTPS发送数据时，会附加一种叫做MAC的报文摘要，MAC能够查知报文是否遭到篡改，从而保证报文的完整性。
Https的通信流程
- 客户端发起HTTPS的请求，携带了客户端支持的加密算法和SSL协议版本号，连接到服务器的443端口。如果是HTTP连接到80端口。
- 配置服务器，采用HTTPS的服务器需要申请一套数字证书（数字证书的本身其实是一对公钥和私钥）。服务器收到请求之后，从加密算法中挑选一种，同时将自己的数字证书以及公钥发送给客户端（私钥自己保留）。
- 客户端验证数字证书，生产一个用于加密传输握手消息的密钥，并使用服务器端传来的公钥对此密钥进行加密。 SSL握手的大致内容【具体细节】
- 交换协议版本号
- 选择一个客户端与服务端都了解的密码
- 对两端的身份进行验证
- 生产临时的会话密钥以便加密信道
- 服务器使用保留的私钥对加密的密钥进行解密，得到密钥信息（完成非对称交换密钥）。
- 使用刚才得到的密钥信息，加密握手信息，发送给客户端，客户端使用相同密钥进行解密验证，完成握手（完成对称加密信息）。
- 进行加密信息传输。
HTTPS的问题
- 通信速度慢：因为要通过SSL
- 处理速度慢：主要是对加密的处理
Socket
套接字（socket）是处于应用层与运输层【TCP/IP模型】中间一组接口（API），是支持TCP/IP协议的网络通信的基本操作单元，TCP/IP协议只是理论，需要通过Socket来实际编码使用。它是网络通信过程中端点的抽象表示，包含进行网络通信必须的五种信息：连接使用的协议（TCP或者UDP），本地主机的IP地址，本地主机进程的协议端口，远程主机的IP地址，远程主机进程的协议端口。Android与IOS都提供了相关的Socket类，这些类提供了一系列的方法，来实现网络连接的各种操作。
应用层通过传输层进行数据通信时，TCP会遇到同时为多个应用程序进程提供并发服务的问题。多个TCP连接或多个应用程序进程可能需要通过同一个 TCP协议端口传输数据。为了区别不同的应用程序进程和连接，许多计算机操作系统为应用程序与TCP／IP协议交互提供了套接字(Socket)接口。应用层可以和传输层通过Socket接口，区分来自不同应用程序进程或网络连接的通信，实现数据传输的并发服务。
简单来说，Socket确定协议，确定客户端与服务端的IP地址与端口后，可以使用其提供的方法来进行网络的相关操作。
建立socket连接
建立Socket连接至少需要一对套接字，其中一个运行于客户端，称为ClientSocket ，另一个运行于服务器端，称为ServerSocket 。
套接字之间的连接过程分为三个步骤：服务器监听，客户端请求，连接确认。
- 服务器监听：服务器端套接字并不定位具体的客户端套接字，而是处于等待连接的状态，实时监控网络状态，等待客户端的连接请求。
- 客户端请求：指客户端的套接字提出连接请求，要连接的目标是服务器端的套接字。为此，客户端的套接字必须首先描述它要连接的服务器的套接字，指出服务器端套接字的地址和端口号，然后就向服务器端套接字提出连接请求。
- 连接确认：当服务器端套接字监听到或者说接收到客户端套接字的连接请求时，就响应客户端套接字的请求，建立一个新的线程，把服务器端套接字的描述发 给客户端，一旦客户端确认了此描述，双方就正式建立连接。而服务器端套接字继续处于监听状态，继续接收其他客户端套接字的连接请求。
SOCKET连接与TCP连接
创建Socket连接时，可以指定使用的传输层协议，Socket可以支持不同的传输层协议（TCP或UDP），当使用TCP协议进行连接时，该Socket连接就是一个TCP连接。
Socket连接与HTTP连接
由于通常情况下Socket连接就是TCP连接，因此Socket连接一旦建立，通信双方即可开始相互发送数据内容，直到双方连接断开。但在实际网 络应用中，客户端到服务器之间的通信往往需要穿越多个中间节点，例如路由器、网关、防火墙等，大部分防火墙默认会关闭长时间处于非活跃状态的连接而导致 Socket 连接断连，因此需要通过轮询告诉网络，该连接处于活跃状态。
而HTTP连接使用的是“请求—响应”的方式，不仅在请求时需要先建立连接，而且需要客户端向服务器发出请求后，服务器端才能回复数据。
很多情况下，需要服务器端主动向客户端推送数据，保持客户端与服务器数据的实时与同步。此时若双方建立的是Socket连接，服务器就可以直接将数 据传送给客户端；若双方建立的是HTTP连接，则服务器需要等到客户端发送一次请求后才能将数据传回给客户端，因此，客户端定时向服务器端发送连接请求， 不仅可以保持在线，同时也是在“询问”服务器是否有新的数据，如果有就将数据传给客户端。TCP(Transmission Control Protocol) 传输控制协议
TCP是主机对主机层的传输控制协议，提供可靠的连接服务，采用三次握手确认建立一个连接:
位码即tcp标志位,有6种标示:SYN(synchronous建立联机) ACK(acknowledgement 确认) PSH(push传送) FIN(finish结束) RST(reset重置) URG(urgent紧急)
Sequence number(顺序号码) Acknowledge number(确认号码)
看了极光推送的 文档 极光的长连接 就是采用TCP 协议来建立的长连接
对TCP 长连接进行内部自己的实现逻辑 来完成长连接的.
尽可能以最小的代价，尽可能地维持连接状态。 因为策略原因，并不会总是在每次断开后马上重新发起连接。
还有Http 有一种 keepalive connections 的机制,可以在数据传输后仍然操持连接,当客户端 需要再次获取数据时,直接使用刚刚空闲下来的连接而无须再次握手.
OAuth
一个用于授权第三方获取相应资源的协议。
它能避免用户暴露自己的用户密码给第三方，更加安全。
它通过设置一个授权层，来区分用户和第三方应用。
用户本身可以通过用户密码来登陆服务提供商，获取到账户的所有资源，而第三方应用只能通过向用户请求授权，获取到一个Access Token，用以登陆授权层，从而在指定时间内获取到用户授权访问的部分资源。
OAuth定义的几个角色：
| 角色 | 描述 |
|---|---|
| Resource Owner | 可以授权访问某些受保护资源的实体，通常就是指用户 |
| Client | 可以通过用户的授权访问受保护资源的应用,也就是第三方应用 |
| Authorization server | 在认证用户之后给第三方下发Access Token的服务器 |
| Resource Server | 拥有受保护资源的服务器，可以通过Access Token响应资源请求 |
1 | +--------+ +---------------+ |
从上图可以看出，一个OAuth授权的流程主要可以分为6步：
- 客户端向用户申请授权
- 用户同意授权
- 客户端通过获取的授权，向认证服务器申请Access Token。
- 认证服务器通过授权后，下发Access Token。
- 客户端通过获取到的Access Token向资源服务器发起请求
- 资源服务器核对Access Token后下发请求资源
DDoS攻击
分布式拒绝服务。一种常见的服务器攻击技术。一般指攻击者利用大量合法的分布式服务器在较短时间内对目标进行大量请求，大规模消耗目标网站的主机资源，让其无法正常服务。用来应对的手段比如，高防服务器，黑名单，DDos 清洗，CDN 加速等。
总结
网络分层：以 TCP/IP 模型为例，分为应用层，传输层，网络层和网络接口层，应用层传递的信息为报文，会根据规则解析传输层发送过来的数据，并决定了向用户提供应用服务时通信的活动。传输层传递的信息为报文段，为两台主机上的应用程序提供段对端的通信，常见如 TCP、UDP 协议。网络层传递的信息为数据报，建立主机到主机的通信，常见如 IP 协议。网络接口层包含数据链路层和物理层，数据链路层传递的信息为帧，主要功能是如何在不可靠的物理线路上保证数据的可靠传输，物理层通俗来讲，就是把计算机链接起来的物理手段。
Http Web服务协议：是用于计算机通过网络进行通信的一种规则。是基于无状态的，请求与响应的，应用层的协议。常基于 TCP/IP 协议（HTTP 使用 TCP 作为它的支撑运输协议）传输数据。默认端口 80。
DNS 域名解析协议（应用层）：用来实现域名和 IP 地址的转换，主要基于 UDP 实现，默认端口 53。
IP 协议（网络层）：它标识了每台主机的唯一性，使用 ARP 协议凭借 MAC 地址进行通信，提供了主机和主机间的通信，像 TCP、UDP 的数据都以 IP 数据格式传输。
TCP 传输控制协议（传输层）：基于 IP 协议，以端口号标识进程，完成两台主机上进程对进程的通信，是面向连接的（三次握手），面向字节流的传输方法（提供可靠的字节流服务）。
UDP 用户数据报协议（传输层）：面向报文的传输方式，只发送原样的报文。
HTTP 报文：指 HTTP 协议交互的信息，分请求报文和响应报文，前者主要包含：请求行、请求头、空行、请求体，后者主要包含：状态行、响应头、空行、响应体。
HTTPS 协议：是身披 SSL 外壳的 HTTP 协议，在 HTTP 协议的基础上，通过加密（保证密码）、认证（验证通信方）、完整性保护（报文的完整）来实现的。默认端口 443。
备忘