本文目标
了解网络编程Java基础
1.OSI 的七层模型
2.TCP的三次握手和四次挥手
3.Http 报文简介
HTTP 协议采用 HTTP 报文的形式传递数据，客户端的报文叫做请求报文；服务器端的报文叫做响应报文。既然是报文，那么一定就会有格式：
请求报文（Request）: 请求头（首部） + 空行 + 请求内容
响应报文（Response）: 响应头（首部） + 空行 + 响应内容
请求内容和响应内容这个应该不用过多的介绍，开发应该都知道，那么请求头到底是啥我们也知道，但是说到具体的一些参数，未必全部知道其作用，所以我们还是详细了解一下请求头和响应头。这里我们需要自己去搭建一个后台做测试，为什么自己去写接口？第一我们可以了解一下后台接口都是怎么写的，第二像Cookie、Session 和 Token 这些都必须和后台配合起来才能测试出作用，总不可能去背吧，我们还是需要自己验证一下。具体操作在末尾视频连接中。接下来我们看下 HTTP 首部都有啥？
4.Http 首部
HTTP 首部字段包含的信息很丰富（特他妈多的意思），我们可以自己打开浏览器观察观察，这样就会有一个更加直观的感受，反正这些首部字段非常重要，无论你是自己去写一个网络框架，还是分析 OkHttp 源码都需要对这些字段有了解，这里我就罗列一些比较常用的做一下解释：
3.1 请求首部字段
Accept：用户代理可处理的媒体类型
Accept-Charset：优先的字符集
Accept-Language：优先的语言（自然语言）
Accept-Encoding：优先的内容编码
If-Modified-Since：比较资源的更新时间
If-Range：资源未更新时发送实体 Byte 的范围请求
Cookie: 设置Cookie（下面会单独讲）
3.2 响应首部字段
Cache-Control：控制缓存的行为（下面会单独讲）
set-Cookie: 设置Cookie（下面会单独讲）
Location：令客户端重定向至指定 URI
Expires：实体主体过期的日期时间
Last-Modified：资源的最后修改日期时间
Status Code: 响应的状态码（下面会单独讲）
4.Cookie、Session 和 Token
4.1 Cookie、Session 和 Token 都是用来做持久化处理的，目的就是让客户端和服务端相互认识。Http 请求默认是不持久的没有状态的，谁也不认识谁。
4.2 Cookie: 是存放在客户端的信息，服务器通过响应头 Set-Cookie 字段给客户端，如果 Cookie 已过期一般是会被清楚的，如果 Cookie 没过期下次访问网站还是会通过请求头的 Cookie 字段带给服务器。
4.3 Session: 是存放在服务器上面的客户端临时信息，用户离开网站是会被清除的。
4.4 Token（App）"令牌"：用户身份的验证，有点类似于 Cookie ，相对来说更安全，一般流程：
3.4.1 客户端向服务端申请 Token
3.4.2 服务端收到请求，会去验证用户信息，签发一个 Token 给客户端，服务端自己也会保存 Token
3.4.3 客户端收到服务端签发的 Token 会保存起来，每次请求带上 Token
3.4.4 服务器收到其他请求，会去验证客户端的 Token , 如果成功返回数据，不成功啥都不给或者做其他处理
5.Http 缓存
关于缓存看下这篇文章就可以了：https://mp.weixin.qq.com/s/qOMO0LIdA47j3RjhbCWUEQ，与缓存相关的有两个重要的字段：
Cache-Control（缓存策略）：Public、private、no-cache、max-age 、no-store（不缓存）
Expires（缓存的过期策略）：指名了缓存数据有效的绝对时间，告诉客户端到了这个时间点（比照客户端时间点）后本地缓存就作废了，在这个时间点内客户端可以认为缓存数据有效，可直接从缓存中加载展示。
还有一种特例，如本地有缓存，但是缓存过期了，这个时候会再次像服务器发起请求，但是服务器数据如果没有变动那么不一定会给你数据，而是返回状态码 304 ，那么什么情况下会返回 304 呢？这个就是《论自己写接口的重要性》我们自己写一个测试接口，测试一下就可以看到这种结果了。
6. Http状态码
1xx: Infomational (信息状态码) ，接收的请求正在处理
2xx: Succeed(成功)，请求正常处理完毕,如 200，204
3xx: Redirection(重定向)，需要进行附加操作，一般是没有响应数据返回的，如 304（Not,modified）307
4xx: Client Error (客户端的错误)，服务器无法处理请求，如 404，405
5xx: Server Error (服务端的错误)，服务器处理请求出错，如 500，502
7. Http 和 Https 的区别
Https = Http + 加密 + 验证 + 完整
Http 的缺点：
7.1 数据是没有加密传输，可能会遭遇窃听；
7.2 不验证通信方的身份，可能会遭遇伪装；
7.3 无法验证报文的完整性，可能会遭遇篡改。
8. SSL握手流程
HTTPS在传输的过程中会涉及到三个密钥：
服务器端的公钥和私钥，用来进行非对称加密
客户端生成的随机密钥，用来进行对称加密
一个HTTPS请求实际上包含了两次HTTP传输，可以细分为8步。
1.客户端向服务器发起HTTPS请求，连接到服务器的443端口
2.服务器端有一个密钥对，即公钥和私钥，是用来进行非对称加密使用的，服务器端保存着私钥，不能将其泄露，公钥可以发送给任何人。
3.服务器将自己的公钥发送给客户端。
4.客户端收到服务器端的证书之后，会对证书进行检查，验证其合法性，如果发现发现证书有问题，那么HTTPS传输就无法继续。严格的说，这里应该是验证服务器发送的数字证书的合法性，关于客户端如何验证数字证书的合法性，下文会进行说明。如果公钥合格，那么客户端会生成一个随机值，这个随机值就是用于进行对称加密的密钥，我们将该密钥称之为client key，即客户端密钥，这样在概念上和服务器端的密钥容易进行区分。然后用服务器的公钥对客户端密钥进行非对称加密，这样客户端密钥就变成密文了，至此，HTTPS中的第一次HTTP请求结束。
5.客户端会发起HTTPS中的第二个HTTP请求，将加密之后的客户端密钥发送给服务器。
6.服务器接收到客户端发来的密文之后，会用自己的私钥对其进行非对称解密，解密之后的明文就是客户端密钥，然后用客户端密钥对数据进行对称加密，这样数据就变成了密文。
7.然后服务器将加密后的密文发送给客户端。
8.客户端收到服务器发送来的密文，用客户端密钥对其进行对称解密，得到服务器发送的数据。这样HTTPS中的第二个HTTP请求结束，整个HTTPS传输完成。
关于客户端如何验证数字证书的合法性
第一 服务器拿自己的公钥和域名信息去认证机构获取证书（CA机构会拿服务器给的所有信息用CA机构的私钥加密生成 数字证书）
第二 客户端本地是有CA机构的公钥的，然后用CA机构的公钥去解密数字证书拿到服务器的公钥
第三 为了防止数字证书在传输过程中被劫持篡改，客户端会用CA的数字证书里面的明文信息使用相同的摘要算法算出一个hash串去和数字证书的hash串比对 如果一致就可以确认 解密出的公钥是合法的 ，到这里客户端的认证就结束了 ras加密通道就建立了
证书中都包含什么?
会包含 域名信息、公钥或者私钥、还有算出的hash串
9. Http 1.x 和 Http 2.0 的区别
网友评论