1.OSI参考模型介绍
- OSI（Open System Interconnection，开放系统互连）七层网络模型称为开放式系统互联参考模型，将服务、接口和协议这三个概念明确地区分开来，：服务说明某一层为上一层提供一些什么功能，接口说明上一层如何使用下层的服务，而协议涉及如何实现本层的服务
OSI 分层 （7 层）：物理层、数据链路层、网络层、传输层、会话层、表示层、应用层
TCP/IP 分层（4 层）：网络接口层、 网际层、运输层、 应用层。
五层协议 （5 层）：物理层、数据链路层、网络层、运输层、 应用层
2.TCP/IP 四层协议
2.1 主机到网络层（数据链路层）
TCP/IP 软件的最低层，负责接收 IP 数据报并通过网络发送之，或者从网络上接收
物理帧，抽出 IP 数据报，交给 IP 层。实际上 TCP/IP 参考模型没有真正描述这一层的实现
2.2 网络互连层（网络层）
**网络互连层是整个 TCP/IP 协议栈的核心。它的功能是把分组发往目标网络或主机。**会沿不同的路径同时进行分组传递，因此，分组到达的顺序和发送的顺序可能不同，这就需要上层必须对分组进行排序。
网络互连层定义了分组格式和协议，即 IP 协议（Internet Protocol）。
完成路由的功能，将不同类型的网络互连，完成拥塞控制的功能，相邻计算机之间的通信
- 处理来自传输层的分组发送请求，收到请求后，将分组装入 IP 数据报，填充报头，选
择去往信宿机的路径，然后将数据报发往适当的网络接口 - 处理输入数据报：首先检查其合法性，然后进行寻径–假如该数据报已到达信宿机，则去掉报头，将剩下部分交给适当的传输协议；假如该数据报尚未到达信宿，则转发该数据报。
- 处理路径、流控、拥塞等问题
2.3 传输层
提供应用程序间的通信，其功能包括：一、格式化信息流；二、提供可靠传输。在 TCP/IP模型中，传输层的功能是使源端主机和目标端主机上的对等实体可以进行会话。在传输层定义了两种服务质量不同的协议。
- TCP（transmission control protoco）：是一个面向连接的、可靠的协议。将一台主机发出的字节流无差错地发往互联网上的其他主机。在发送端，它负责把上层传送下来的字节流分成报文段并传递给下层，在接收端，它负责把收到的报文进行重组后递交给上层
- UDP 协议是一个不可靠的、无连接协议，主要适用于不需要对报文进行排序和流量控制的场合。
2.4 应用层
TCP/IP 模型将 OSI 参考模型中的会话层和表示层的功能合并到应用层实现
3. OSI 和 TCP/IP 区别
3.1 区别
- 网际协议的支持情况不同，TCP/IP 一开始就考虑到多种异构网的互连问题，并将网际协
议 IP 作为 TCP/IP 的重要组成部分。 - 无线连接服务的支持标准不同，TCP/IP 一开始就对面对连接服务和无连接服务并重，而
OSI 在开始的时只强调面向连接这一种服务。一直到很晚 OSI 才开始制定另一种无连接服务
的有关标准。 - 网络管理能力不同，TCP/IP 较早就有很好的网络管理功能，而 OSI 到后来才考虑这个问
题。TCP/IP 的不足 : TCP/IP 模型对“服务”，“协议”和“接口”等概念没有很清楚的区分开，TCP/IP 模型的通用性比较差。
3.2 相同
- 都是采用协议分层的方法，将庞大且复杂的问题划分为若干个较为容易处理的范围较小
的问题 - 各协议层次的功能大体上相似，都存在网络层，传输层和应用层。各协议层次的功能大体上相似，都存在网络层，传输层和应用层。传输层实现端到端通信，将高层的用户应用与低层的通信子网隔离开来，并保证数据传输的最终可靠性。
- 两者都可以解决异构网的互连，实现世界上不同厂家生产的计算机之间的通信
- 都是计算机通信的国际标准，OSI 原则上是国际通用，TCP/IP 是当前工业界使用最多的
4.Http
HTTP 是超文本传输协议，也就是 HyperText Transfer Protocol。HTTP 是一个在计算机世界里专门在「两点」之间「传输」文字、图片、音频、视频等「超文本」数据的「约定和规范」。PS：HTTP 不止是从互联网服务器传输超文本到本地浏览器的协议，还是服务器到
服务器之间的传输协议
4.1 工作方式
浏览器：?户输?地址后回?或点击链接 -> 浏览器拼装HTTP报?并发送请求给服务器->服务器处理请求后发送响应报?给浏览器 -> 浏览器解析响应报?并使?渲染引擎显示到界?
手机APP：?户点击或界??动触发联?需求 -> Android代码调?拼装HTTP报?并发送请求到服务器 -> 服务器处理请求后发送响应报?给?机 -> Android代码处理响应报?并作出相应处理（如储存数据、加?数据、显示数据到界?）
4.2 URL 和 HTTP 报文
4.2.1 URL格式
三部分：协议类型、服务器地址(和端?号)、路径(Path)
协议类型://服务器地址[:端?号]路径
4.2.2 报文格式
请求报文
HTTP 请求报文由请求行、请求头部、空行 和 请求包体 4 个部分组成
响应报文
4.2.3 Request Method 请求方法
1 GET
- ?于获取资源
- 对服务器数据不进?修改
- 不发送Body
GET /users/1 HTTP/1.1
Host: api.github.com
对应Retrofit的代码：
@GET("/users/{id}")
Call<User> getUser(@Path("id") String id,
@Query("gender") String gender);
2 POST
- ?于增加或修改资源
- 发送给服务器的内容写在Body??
POST /users HTTP/1.1
Host: api.github.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 13
name=rengwuxian&gender=male
对应Retrofit的代码：
@FormUrlEncoded
@POST("/users")
Call<User> addUser(@Field("name") String name,
@Field("gender") String gender);
3 PUT
- ?于修改资源
- 发送给服务器的内容写在Body??
PUT /users/1 HTTP/1.1
Host: api.github.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 13
gender=female
对应Retrofit的代码
@FormUrlEncoded
@PUT("/users/{id}")
Call<User> updateGender(@Path("id") String id,
@Field("gender") String gender);
4 DELETE
- ?于删除资源
- 不发送Body
DELETE /users/1 HTTP/1.1
Host: api.github.com
对应Retrofit的代码
@DELETE("/users/{id}")
Call<User> getUser(@Path("id") String id,
@Query("gender") String gender);
5 HEAD
和GET使??法完全相同，和GET唯?区别在于，返回的响应中没有Body
4.3 状态码 Status Code
三位数字，
?于对响应结果做出类型化描述（如「获取成功」「内容未找到」）
1xx：临时性消息。如：100（继续发送）、101（正在切换协议）
2xx：成功。最典型的是200（OK）、201（创建成功）。
3xx：重定向。如301（永久移动）、302（暂时移动）、304（内容未改变）。
4xx：客户端错误。如400（客户端请求错误）、401（认证失败）、403（被禁?）、404
（找不到内容）。
5xx：服务器错误。如500（服务器内部错误）
4.4 Header首部
作?：HTTP消息的metadata
4.4.1 Host
目标主机，不是在?络上?于寻址的，?是在?标服务器上?于定位?服务器的。
4.4.2 Content-Type
指定body的类型
1. 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">
2. 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=rengwuxian&gender=male
对应的Retrofit代码
@FormUrlEncoded
@POST("/users")
Call<User> addUser(@Field("name") String name,
@Field("gender") String gender);
3. multipart/form-data
web??含有?进制?件时的提交?式。
格式如下：
POST /users HTTP/1.1
Host: hencoder.com
Content-Type: multipart/form-data; boundary=----
WebKitFormBoundary7MA4YWxkTrZu0gW
Content-Length: 2382
------WebKitFormBoundary7MA4YWxkTrZu0gW
Content-Disposition: form-data; name="name"
rengwuxian
------WebKitFormBoundary7MA4YWxkTrZu0gW
Content-Disposition: form-data; name="avatar";
filename="avatar.jpg"
Content-Type: image/jpeg
JFIFHHvOwX9jximQrWa......
------WebKitFormBoundary7MA4YWxkTrZu0gW--
对应的Retrofit的代码：
@Multipart
@POST("/users")
Call<User> addUser(@Part("name") RequestBodyname,
@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);
4. application/json , image/jpeg , application/zip …
单项内容（?本或??本都可以），?于Web Api的响应或者POST / PUT的请求
POST /users HTTP/1.1
Host: hencoder.com
Content-Type: application/json; charset=utf-8
Content-Length: 38
{"name":"rengwuxian","gender":"male"}
对应Retrofit的代码
@POST("/users")
Call<User>
addUser(@Body("user") User
user);
...
//需要使?JSON相关的Converter
api.addUser(user);
响应中返回JSON
HTTP/1.1 200 OK
content-type: application/json; charset=utf-8
content-length: 234
[{"login":"mojombo","id":1,"node_id":"MDQ6VXNl
cjE=","avatar_url":"https://avatars0.githubuse
rcontent.com/u/1?v=4","gravat.....
请求中提交?进制内容
POST /user/1/avatar HTTP/1.1
Host: hencoder.com
Content-Type: image/jpeg
Content-Length: 1575
JFIFHH9....
对应Retrofit的代码：
@POST("users/{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......
4.5 其他
4.5.1 Content-Length
指定Body的长度（字节）
4.5.2 Transfer: chunked (分块传输编码Chunked Transfer Encoding)
?于当响应发起时，内容?度还没能确定的情况下。和Content-Length不同时使?。
?途是尽早给出响应，减少?户等待
格式：
HTTP/1.1 200 OK
Content-Type: text/html
Transfer-Encoding: chunked
4
Chun
9
ked Trans
12
fer Encoding
0//表示结束
4.5.3 Location
指向重定向的目标URL
4.5.4 User-Agent
?户代理，即是谁实际发送请求、接受响应的，例如?机浏览器、某款?机App。
Range / Accept-Range按范围取数据
Accept-Range: bytes 响应报?中出现，表示服务器?持按字节来取范围数据
Range: bytes=- 请求报?中出现，表示要取哪段数据
Content-Range:-/total 响应报?中出现，表示发送的是哪段数据
作?：断点续传、多线程下载
4.5.5 其他Headers
Accept:客户端能接受的数据类型。如text/html
Accept-Charset:客户端接受的字符集。如utf-8
Accept-Encoding:客户端接受的压缩编码类型。如gzip
Content-Encoding：压缩类型。如gzip
4.5.6 Cashe
作?：在客户端或中间?络节点缓存数据，降低从服务器取数据的频率，以提??络性能
4.6 REST
REST HTTP 即正确使?HTTP
包括：使?资源的格式来定义URL，规范地使?method来定义?络请求操作，规范地使?status code来表示响应状态，其他符合HTTP规范的设计准则。
4.7优点
优点是「简单、灵活和易于扩展、应用广泛和跨平台」。
- 简单，HTTP 基本的报文格式就是 header + body ，头部信息也是 key-value 简单文本的形式
- 灵活和易于扩展，HTTP 协议里的各类请求方法、URI/URL、状态码、头字段等每个组成要求都没有被固定死，都允许开发人员自定义和扩充。同时 HTTP 由于是工作在应用层（ OSI 第七层），则它下层可以随意变化。HTTPS 也就是在 HTTP 与 TCP 层之间增加了SSL/TLS 安全传输层。
- 应用广泛和跨平台，互联网发展至今，HTTP 的应用范围非常的广泛
4.8优缺点一体
「无状态、明文传输、不安全」
- 无状态
好处，因为服务器不会去记忆 HTTP 的状态，所以不需要额外的资源来记录状态信息，这能减轻服务器的负担，能够把更多的 CPU 和内存用来对外提供服务。
坏处，既然服务器没有记忆能力，它在完成有关联性的操作时会非常麻烦。可以使用Cookie技术解决，Cookie 通过在请求和响应报文中写入 Cookie 信息来控制客户端的状态。相当于，在客户端第一次请求后，服务器会下发一个装有客户信息的「小贴纸」，后续客户端请求服务器的时候，带上「小贴纸」，服务器就能认得了。 - 明文传输
明文意味着在传输过程中的信息，是可方便阅读的，通过浏览器的 F12 控制台或Wireshark抓包都可以直接肉眼查看，为我们调试工作带了极大的便利性。但是这正是这样，HTTP 的所有信息都暴露了，在传输的漫长的过程中，信息的内容都毫无隐私可言，很容易就能被窃取。 - 不安全
HTTP 比较严重的缺点就是不安全：通信使用明文（不加密），内容可能会被窃听。
4.9 性能
- 长连接
HTTP/1.1 提出了长连接的通信方式，减少了 TCP 连接的重复建立和断开所造成的额外开销，减轻了服务器端的负载。持久连接的特点是，只要任意一端没有明确提出断开连接，则保持 TCP 连接状态。 - 管道网络传输
即可在同一个 TCP 连接里面，客户端可以发起多个请求，只要第一个请求发出去了，不必等其回来，就可以发第二个请求出去，可以减少整体的响应时间。但是服务器还是按照顺序，先回应 A 请求，完成后再回应 B 请求。要是前面的回应特别慢，后面就会有许多请求排队等着。这称为「队头堵塞」。 - 对头阻塞
当顺序发送的请求序列中的一个请求因为某种原因被阻塞时，在后面排队的所有请求也一同被阻塞了，会招致客户端一直请求不到数据。
5.Https
5.1 https和http的区别
- http 是超文本传输协议，其中的信息是明文传输的。https 是 http 协议再加上 SSL（安全
套接字层），具有安全性。 - http 不验证通信方的身份，通信方的身份有可能遭遇伪装；https 需要到 CA （证书颁发机构）申请证书。
- http 和 https 使用的是完全不同的连接方式，用的端口也不一样，前者是 80，后者是 443
- http 无法证明报文的完整性，报文有可能遭篡改。
- http 的连接很简单，是无状态的；HTTPS 协议是由 SSL+HTTP 协议构建的可进行加密传输、身份认证的网络协议，比 http 协议安全。
- HTTPS 连接缓存不如 HTTP 高效，流量成本高
- HTTPS 连接服务器端资源占用高很多，支持访客多的网站需要投入更大的成本
HTTP是明文传输，有窃听，篡改，冒充的风险，HTTPS 在 HTTP 与 TCP 层之间加入了SSL/TLS 协议，可以很好的解决了上述的风险：
信息加密：交互信息无法被窃取
校验机制：无法篡改通信内容，篡改了就不能正常显示
身份证书
5.2 Https加密方式
让 HTTP 先和 SSL（Secure Sockets Layer）通信，再由 SSL 和 TCP 通信，也就是说 HTTPS 使用了隧道进行通信。通过使用 SSL，HTTPS 具有了加密（防窃听）、认证（防伪装）和完整性保护（防篡改）。
在客户端和服务器之间协商出?套对称密钥，每次发送信息之前将内容加密，收到
之后解密，达到内容的加密传输
**不直接使用非对称加密：**?对称加密由于使?了复杂了数学原理，因此计算相当复杂，如果完全使??对称加密来加密通信内容，会严重影响?络通信的性能。
**1.认证：**使用数字证书认证机构来对通信方进行认证，将服务器公钥放入到数字证书中，解决了冒充的风险。需要借助第三方权威机构 CA （数字证书认证机构），将服务器公钥放在数字证书（由数字证书认证机构颁发）中，只要证书是可信的，公钥就是可信的
**2.混合加密：**采用的是对称加密和非对称加密结合的「混合加密」方式，传输数据用对称加密方式，对称加密生成的秘钥用非对称加密方式。
1. 在通信建立前采用非对称加密的方式交换「会话秘钥」
2. 在通信过程中全部使用对称加密的「会话秘钥」的方式加密明文数据
原因：
1.对称加密只使用一个密钥，运算速度快，密钥必须保密，无法做到安全的密钥交换
2.非对称加密使用两个密钥：公钥和私钥，公钥可以任意分发而私钥保密，解决了密钥交
换问题但速度慢
3.整体过程：
客户端和服务端在开始传输数据之前，会协商传输过程需要使用的加密算法。客户端发送协商请求给服务端, 其中包含自己支持的非对称加密的密钥交换算法 ( 一般是RSA)，数据签名摘要算法 ( 一般是SHA或者MD5) , 加密传输数据的对称加密算法 ( 一般是DES)，以及加密密钥的长度。
服务端接收到消息之后，选中安全性最高的算法，并将选中的算法发送给客户端，完成协商。
客户端生成随机的字符串，通过协商好的非对称加密算法，使用服务端的公钥对该字符串进行加密，发送给服务端。
服务端接收到之后，使用自己的私钥解密得到该字符串。在随后的数据传输当中，使用这个字符串作为密钥进行对称加密
6. SSL/TLS 流程
SSL 是 “Secure Sockets Layer 的缩写，中文叫做「安全套接层」
TLS是 “TransportLayer Security” 的缩写，中文叫做「传输层安全协议」
这两者可以视作同一个东西的不同阶段
6.1 基本流程
- 客户端向服务器索要并验证服务器的公钥。
- 双方协商生产「会话秘钥」
- 双方采用「会话秘钥」进行加密通信。
6.2 服务器认证阶段
- ClientHello：由客户端向服务器发起加密通信请求。
会发送：- 客户端支持的 SSL/TLS 协议版本
- 客户端生产的随机数（ Client Random ），后面用于生产「会话秘钥」
- 客户端支持的密码套件列表，如 RSA 加密算法
- SeverHello：服务器收到客户端请求后，向客户端发出响应
响应内容：- 确认 SSL/ TLS 协议版本，如果浏览器不支持，则关闭加密通信。
- 服务器生产的随机数（ Server Random ），后面用于生产「会话秘钥」。
- 确认的密码套件列表，如 RSA 加密算法
- 服务器的数字证书。
- 客户端回应
客户端收到服务器的回应之后，首先通过浏览器或者操作系统中的 CA 公钥，确认服务器 的数字证书的真实性。如果证书没有问题，客户端会从数字证书中取出服务器的公钥，然后使用它加密报文，向服务器发送如下信息：- 一个随机数（ pre-master key ）。该随机数会被服务器公钥加密，该随机数是整个握 手阶段的第三个随机数，接着就用双方协商的加密算法，各自生成本次通信的「会话秘钥」
- 加密通信算法改变通知，表示随后的信息都将用「会话秘钥」加密通信
- 客户端握手结束通知，表示客户端的握手阶段已经结束。这一项同时把之前所有内容的
发生的数据做个摘要，用来供服务端校验
- 服务器的最后回应
- 服务器收到客户端的第三个随机数（ pre-master key ）之后，通过协商的加密算法，计算出本次通信的「会话秘钥」。然后，向客户端发生最后的信息：
- 加密通信算法改变通知，表示随后的信息都将用「会话秘钥」加密通信
- 服务器握手结束通知，表示服务器的握手阶段已经结束，这一项同时把之前所有内容
的发生的数据做个摘要，用来供客户端校验
- 服务器收到客户端的第三个随机数（ pre-master key ）之后，通过协商的加密算法，计算出本次通信的「会话秘钥」。然后，向客户端发生最后的信息：
6.3 用户认证阶段
经认证的服务器发送一个提问给客户，客户则返回（数字）签名后的提问和其公开密钥，从而向服务器提供认证。就是使用普通的 HTTP 协议，只不过用「会话秘钥」加密内容。