TCP/IP 网络模型
TCP/IP 网络模型
应用层,传输层，网络层，链路层
TCP、UDP
TCP报文段
源端口号和目标端口号：谁发的和发给谁(类似于哲学问题：你是谁？从哪里来？到哪里去？)；
序号：为了解决乱序问题；
确认序号：发出去的包应该有确认，没有收到就应该重新发送，直到送达；
状态位：常见的有SYN、ACK、FIN，分别表示发起一个连接、确认和结束连接；
窗口大小：用于TCP流量控制，通信双方各声明一个窗口，说明自己当前的处理能力。发送的太快，处理不了，发的太慢，影响发送的效率；
TCP的三次握手
防止服务器端开启一些无用的连接增加服务器开销以及防止已失效的连接请求报文段突然又传送到了服务端，因而产生错误。
通过序列号（SYN）与确认应答（ACK）提高可靠性，如果丢包则重发
注意：服务器端的资源是在完成第二次握手时分配的，而客户端的资源是在完成第三次握手时分配的。所以服务器易于受到SYN洪泛攻击。
TCP的四次挥手
TCP释放连接时之所以需要“四次挥手”,是因为FIN释放连接报文与ACK确认接收报文是分别由第二次和第三次”握手”传输的。但是建立连接时可以一起传输，释放连接时需要做一些后续处理，无法立即返回。
TCP的11种状态
CLOSED：初始状态，表示TCP连接是“关闭着的”或“未打开的”。
LISTEN：表示服务器端的某个SOCKET处于监听状态，可以接受客户端的连接。
SYN_RCVD：表示服务器接收到了来自客户端请求连接的SYN报文。
SYN_SENT：表示客户端已发送SYN报文。
ESTABLISHED：表示TCP连接已经成功建立。
FIN_WAIT_1：
FIN_WAIT_2：
TIME_WAIT：
CLOSING ：
CLOSE_WAIT ：表示正在等待关闭。
LAST_ACK ：当被动关闭的一方在发送FIN报文后，等待对方的ACK报文的时候，就处于LAST_ACK 状态。
CLOSING状态：产生的原因是客户端和服务端同时关闭
TCP和UDP的区别
1.是否连接:TCP面向连接（如打电话要先拨号建立连接）;UDP是无连接的，即发送数据之前不需要建立连接
2.传输可靠性:TCP可靠,UDP不可靠,TCP提供可靠的服务。也就是说，通过TCP连接传送的数据，无差错，不丢失，不重复，且按序到达;UDP尽最大努力交付，即不保证可靠交付
3.速度:TCP慢,UDP快
4.对系统资源的要求:TCP较多，UDP少
5.应用场合:TCP少量数据,UDP传输大量数据,TCP面向字节流，实际上是TCP把数据看成一连串无结构的字节流;UDP是面向报文的
UDP没有拥塞控制，因此网络出现拥塞不会使源主机的发送速率降低（对实时应用很有用，如IP电话，实时视频会议等）
6.每一条TCP连接只能是点到点的;UDP支持一对一，一对多，多对一和多对多的交互通信
7.TCP的逻辑通信信道是全双工的可靠信道，UDP则是不可靠信道
TCP如何保证可靠传输
TCP靠确认重传机制、滑动窗口机制进行流量控制、慢开始算法等进行拥塞控制。
TCP使用了校验、序号、确认和重传机制来达到这个目的。
校验：用来校验数据准确性，在计算校验和时，要在TCP数据报之前增加12个字节的伪首部，伪首部并不是TCP报文段真正的首部。
序号：TCP连接中传送的数据流中的每一个字节都编上一个序号。序号字段的值则指的是本报文段所发送的数据的第一个字节的序号。
确认：TCP首部的确认号是期望收到对方的下一个报文段的数据的第一个字节的序号。TCP默认使用累计确认，即TCP只确认数据流中至第一个丢失字节为止的字节。例如，接收方B收到了发送方A发送的包含字节0~2和6~7的报文段。由于某些原因，B还没有收到字节3~5的报文段，此时B仍在等待字节3(和其后面的字节)，因此，B到A的下一个报文段将确认号字段设置为3。
重传：有两种事件会导致TCP对报文段进行重传：超时和冗余ACK。只要计时器设置的重传时间到期但还没有收到确认，就要重传这一报文段。TCP规定当发送方收到对同一个报文段的3个冗余ACK时，就可以认为跟在这个被确认报文段之后的报文段已经丢失。
TCP流量控制
TCP提供了流量控制服务以消除发送方使接收方缓存区溢出的可能性，因此TCP流量控制是为了匹配发送方的发送速率与接收方的读取速率。TCP提供一种基于滑动窗口协议的流量控制机制。其原理是：在通信过程中，接收方根据自己接收缓存的大小，动态地调整发送方的发送窗口大小，这就是接收窗口rwnd，即调整TCP报文段首部中的"窗口"字段的值，来限制发送方向网络注入报文的速率。同时，发送方根据其对当前网络拥塞程度的估计而确定窗口值，称为拥塞窗口cwnd，其大小与网络的带宽和时延密切相关。
TCP拥塞控制
为了更好地对传输层进行拥塞控制，有以下四种算法：慢开始、拥塞避免、快重传、快恢复。发送方在确定发送报文段的速率时，既要根据接收方的接收能力，又要从全局考虑不要使网络发生拥塞。因此，TCP协议要求发送方维护以下两个窗口：
(1)接收窗口rwnd，接收方根据目前接收缓存大小所许诺的最新的窗口值，反映了接收方的容量。有接收方根据其放在TCP报文的首部的"窗口"字段通知发送方。
(2)拥塞窗口cwnd，发送方根据自己估算的网络拥塞程度而设置的窗口值，反映了网络当前容量。只要网络没有出现拥塞，拥塞窗口就再增大一些，以便把更多的分组发送出去。但只要网络出现拥塞，拥塞窗口就减少一些，以减少注入网络中的分组数。发送窗口的上限值应当取接收窗口rwnd和拥塞窗口cwnd中较小的一个，即：Min[rwnd, cwnd]。
拥塞控制与流量控制的区别
拥塞控制是让网络能够承受现有的网络负荷，它是一个全局性的过程，涉及所有的主机、所有的路由器，以及与降低网络传输性能有关的所有因素。而流量控制往往使指点对点通信量的控制，即接收端控制发送端，它所做的就是抑制发送端发送数据的速率，以便使接收端来得及接收。
TCP 滑动窗口
发送窗口收到接收端对于本段窗口内字节的 ACK 确认才会移动发送窗口的左边界。
接收窗口只有在前面所有的段都确认的情况下才会移动左边界，当前面还有字节未接收但收到后面字节的情况下(乱序)窗口是不会移动的，并不对后续字节确认, 确保这段数据重传。
可以根据滑动窗口的调整进行流量控制。
是否TCP和UDP都需要计算往返时间RTT？
往返时间RTT只是针对传输层TCP协议才很重要，因为TCP要根据RTT的值来设置超时计时器的超时时间。UDP没有确认和重传机制，因此RTT对UDP没有什么意义。
为什么TCP在建立连接的时候不能每次选择相同的、固定的初始序号？
必须使得迟到的TCP报文段的序号不在新的连接中使用的序号范围内。所以，TCP在建立新的连接时所选择的初始序号一定要和前面的一些连接所使用过的序号不一样。因此，不同的TCP连接不能使用相同的初始序号。
HTTP
Http的报文结构
请求报文:
请求行：请求方法（Method） + 空格 + 统一资源标识符（URI） + 空格 + HTTP版本；
请求头：字段名 + 冒号 + 值 + CR LF ；
空行： 回车符（CR）+ 换行符（LF） ；
请求体： 由用户自定义添加，如post的body等；
响应报文:
状态行：HTTP版本 + 空格 + 状态码 + 空格 + 状态码描述；
响应头：字段名 + 冒号 + 值 + CR LF ；
空行： 回车符（CR）+ 换行符（LF） ；
响应体： 由用户自定义添加，如post的body等；
响应状态码：
1xx（信息）：收到请求，继续处理
2xx（成功）：请求已成功接收，理解和接受
3xx（重定向）：需要采取进一步措施才能完成请求
4xx（客户端错误）：请求包含错误的语法或无法满足
5xx（服务器错误）：服务器无法满足明显有效的请求
Http的请求方法
GET 请求指定的页面信息，并返回实体主体。
HEAD 类似于 GET 请求，只不过返回的响应中没有具体的内容，用于获取报头
POST 向指定资源提交数据进行处理请求（例如提交表单或者上传文件）。数据被包含在请求体中。POST 请求可能会导致新的资源的建立和/或已有资源的修改。
PUT 从客户端向服务器传送的数据取代指定的文档的内容。
DELETE 请求服务器删除指定的页面。
CONNECT HTTP/1.1 协议中预留给能够将连接改为管道方式的代理服务器。
OPTIONS 允许客户端查看服务器的性能。
TRACE 回显服务器收到的请求，主要用于测试或诊断。
PATCH 是对 PUT 方法的补充，用来对已知资源进行局部更新 。
HTTP抓包的原理
直接抓路由器的包比较麻烦，一般会在手机和本地路由之间加一层代理服务，抓代理服务的网络数据即可。
https原理
在tcp和http之间加了一层SSL/TLS协议。
SSL/TLS协议通过非对称加密实现证书验证，通过对称加密实现数据传输。
证书验证阶段：浏览器发起 HTTPS 请求。服务端返回 HTTPS 证书。客户端验证证书是否合法，如果不合法则提示告警。
数据传输阶段：当证书验证合法后，在本地生成随机数。通过公钥加密随机数，并把加密后的随机数传输到服务端。服务端通过私钥对随机数进行解密。服务端通过客户端传入的随机数构造对称加密算法，对返回结果内容进行加密后传输。
HTTPS可以有效的防止运营商劫持，解决了防劫持的一个大问题。
HTTP1.0和HTTP1.1的一些区别
HTTP1.1是当前使用最为广泛的HTTP协议。 主要区别主要体现在：
长连接，可以重用连接，从而节省了多次重新打开连接的时间。
流水线，添加了流水线，允许在完全传输第一个请求的答案之前发送第二个请求，从而降低了通信延迟。
缓存处理，在HTTP1.0中主要使用header里的If-Modified-Since,Expires来做为缓存判断的标准，HTTP1.1则引入了更多的缓存控制策略例如Entity tag，If-Unmodified-Since, If-Match, If-None-Match等更多可供选择的缓存头来控制缓存策略。
带宽优化及网络连接的使用，HTTP1.0中，存在一些浪费带宽的现象，例如客户端只是需要某个对象的一部分，而服务器却将整个对象送过来了，并且不支持断点续传功能，HTTP1.1则在请求头引入了range头域，它允许只请求资源的某个部分，即返回码是206（Partial Content），这样就方便了开发者自由的选择以便于充分利用带宽和连接。
错误通知的管理，在HTTP1.1中新增了24个错误状态响应码，如409（Conflict）表示请求的资源与资源的当前状态发生冲突；410（Gone）表示服务器上的某个资源被永久性的删除。
Host头处理，在HTTP1.0中认为每台服务器都绑定一个唯一的IP地址，因此，请求消息中的URL并没有传递主机名（hostname）。但随着虚拟主机技术的发展，在一台物理服务器上可以存在多个虚拟主机（Multi-homed Web Servers），并且它们共享一个IP地址。HTTP1.1的请求消息和响应消息都应支持Host头域，且请求消息中如果没有Host头域会报告一个错误（400 Bad Request）。
SPDY
HTTP1.x的优化，优化了HTTP1.X的请求延迟，解决了HTTP1.X的安全性，SPDY位于HTTP之下，TCP和SSL之上，这样可以轻松兼容老版本的HTTP协议。主要优化如下：
降低延迟，针对HTTP高延迟的问题，SPDY优雅的采取了多路复用（multiplexing）。多路复用通过多个请求stream共享一个tcp连接的方式，解决了HOL blocking的问题，降低了延迟同时提高了带宽的利用率。
请求优先级（request prioritization）。多路复用带来一个新的问题是，在连接共享的基础之上有可能会导致关键请求被阻塞。SPDY允许给每个request设置优先级，这样重要的请求就会优先得到响应。比如浏览器加载首页，首页的html内容应该优先展示，之后才是各种静态资源文件，脚本文件等加载，这样可以保证用户能第一时间看到网页内容。
header压缩。前面提到HTTP1.x的header很多时候都是重复多余的。选择合适的压缩算法可以减小包的大小和数量。
基于HTTPS的加密协议传输，大大提高了传输数据的可靠性。
服务端推送（server push），采用了SPDY的网页，例如我的网页有一个sytle.css的请求，在客户端收到sytle.css数据的同时，服务端会将sytle.js的文件推送给客户端，当客户端再次尝试获取sytle.js时就可以直接从缓存中获取到，不用再发请求了。
HTTP2.0
HTTP2.0可以说是SPDY的升级版（其实原本也是基于SPDY设计的），但是，HTTP2.0 跟 SPDY 仍有不同的地方，如下：
HTTP2.0和SPDY的区别
HTTP2.0 支持明文 HTTP 传输，而 SPDY 强制使用 HTTPS
HTTP2.0 消息头的压缩算法采用 HPACK http://http2.github.io/http2-spec/compression.html，而非 SPDY 采用的 DEFLATEhttp://zh.wikipedia.org/wiki/DEFLATE
HTTP2.0和HTTP1.X相比的新特性
多路复用（MultiPlexing），即连接共享，即每一个request都是是用作连接共享机制的。一个request对应一个id，这样一个连接上可以有多个request，每个连接的request可以随机的混杂在一起，接收方可以根据request的 id将request再归属到各自不同的服务端请求里面。
header压缩，如上文中所言，对前面提到过HTTP1.x的header带有大量信息，而且每次都要重复发送，HTTP2.0使用encoder来减少需要传输的header大小，通讯双方各自cache一份header fields表，既避免了重复header的传输，又减小了需要传输的大小。
新的二进制格式（Binary Format），HTTP1.x的解析是基于文本。基于文本协议的格式解析存在天然缺陷，文本的表现形式有多样性，要做到健壮性考虑的场景必然很多，二进制则不同，只认0和1的组合。基于这种考虑HTTP2.0的协议解析决定采用二进制格式，实现方便且健壮。
服务端推送（server push），同SPDY一样，HTTP2.0也具有server push功能。
HTTP2.0的升级改造
前文说了HTTP2.0其实可以支持非HTTPS的，但是现在主流的浏览器像chrome，firefox表示还是只支持基于 TLS 部署的HTTP2.0协议，所以要想升级成HTTP2.0还是先升级HTTPS为好。
升级了HTTP2.0那么，原本的HTTP1.x怎么办，这个问题其实不用担心，HTTP2.0完全兼容HTTP1.x的语义，对于不支持HTTP2.0的浏览器，NGINX会自动向下兼容的。
HTTP2.0的多路复用和HTTP1.X中的长连接复用的区别？
HTTP/1.1 Pipeling解决方式为，若干个请求排队串行化单线程处理，后面的请求等待前面请求的返回才能获得执行机会，一旦有某请求超时等，后续请求只能被阻塞，毫无办法，也就是人们常说的线头阻塞；
HTTP/2多个请求可同时在一个连接上并行执行。某个请求任务耗时严重，不会影响到其它连接的正常执行；
HTTP2.0为什么需要头部压缩
假定一个页面有100个资源需要加载（这个数量对于今天的Web而言还是挺保守的）, 而每一次请求都有1kb的消息头（这同样也并不少见，因为Cookie和引用等东西的存在）, 则至少需要多消耗100kb来获取这些消息头。HTTP2.0可以维护一个字典，差量更新HTTP头部，大大降低因头部传输产生的流量。具体参考：HTTP/2 头部压缩技术介绍
HTTP2.0多路复用有多好
HTTP 性能优化的关键并不在于高带宽，而是低延迟。TCP 连接会随着时间进行自我「调谐」，起初会限制连接的最大速度，如果数据成功传输，会随着时间的推移提高传输的速度。这种调谐则被称为 TCP 慢启动。由于这种原因，让原本就具有突发性和短时性的 HTTP 连接变的十分低效。
HTTP/2 通过让所有数据流共用同一个连接，可以更有效地使用 TCP 连接，让高带宽也能真正的服务于 HTTP 的性能提升。
解决了线头阻塞的问题，减少了 TCP 连接数量和 TCP 连接慢启动造成的问题.http2 对于同一域名只需要创建一个连接，而不是像 http/1.1 那样创建 6~8 个连接。
HTTP3.0有什么改进
HTTPS 如何防范中间人攻击
通过CA证书和非对称加密传输随机数私钥。
请解释安卓为啥要加签名机制
为了安全，防止apk被修改。签名过的apk被人修改后都会校验失败，如果伪造数字签名也不行，因为没有数字证书对应的私钥。所以，如果要重新打包修改后的应用程序能再Android设备上安装，必须对其进行重签名。
通常情况下，Android 为所有的应用程序开发者推荐的签名策略是，所有的应用程序都应该使用同一个证书进行签名，并且证书的有效期应该长于应用程序的生命周期。这样做的原因有以下三点：
1）应用程序升级。
若开发者希望某应用程序可以无缝升级到新版本，则新旧版本应用程序必须使用同一个证书进行签名，否则不能升级。
如果使用的不是同一个证书签名，则新的应用程序会被安装到一个完全不同的目录下，相当于安装了一个新的应用程序，而旧的应用程序不能升级。
2）应用程序模块化。
Android 系统允许多个以同一个证书签名的应用程序运行在同一个进程中，并将其看作一个应用程序。每个应用程序可以以模块化部署，在升级时可以独立地升级其中的某一个模块。
3）允许代码或者数据共享。
Android 提供了以签名为基础的权限机制，应用程序可以为以相同证书签名的其他应用程序公开自己的功能，这样就可以在相同签名的应用程序之间共享代码和数据。
客户端如何校验 CA 证书
android api校验，也可以实现自定义CA证书
Android中使用Https
Android 9.0 将默认所有app使用HTTPS，如果app想使用http，需要在配置文件额外配置。
Android 使用的是 Java 的 API。那么 HTTPS 使用的 Socket 必然都是通过SSLSocketFactory 创建的 SSLSocket，当然自己实现了 TLS 协议除外。一个典型的使用 HTTPS 方式如下: （ps：网络连接方式有HttpClient(5.0开始废弃)、HttpURLConnection、OKHttp 和 Volley）。默认的 SSLSocketFactory 校验服务器的证书时，会信任设备内置的100多个根证书。
如果不加载自己的证书，系统会为你配置好一个安全的 SSL，但系统默认的 SSL认为一切 CA 都是可信的，可往往 CA 有时候也不可信，比如某家 CA 被黑客入侵什么的事屡见不鲜。虽然 Android 系统自身可以更新信任的 CA 列表，以防止一些 CA 的失效，如果为了更高的安全性，可以希望指定信任的锚点，
Android中使用Http2.0
当后端支持的协议内包含Http2.0时，则就会把请求升级到Http2.0阶段。
OKHTTP
Okhttp设计之初就是一个java平台通用的网络库，对于不同的java版本，还有安卓的底层适配逻辑是不同的。简单的说Okhttp就是抽象了下所有Tls，SSLSocket相关的代码，然后通过一个Platform，根据当前使用环境的不同，去反射调用不同的实现类，然后这个抽象的类去调用Platform的实现类代码，做到多平台的兼容。
其中Tls当生成好SSLSocket之后，就会开始进行client say hello 和server say hello的操作了，这部分完全和https定义的一模一样。Handshake则会把服务端支持的Tls版本，加密方式等都带回来，然后会把这个没有验证过的HandShake用X509Certificate去验证证书的有效性。然后会通过Platform去从SSLSocket去获取ALPN的协议支持信息，当后端支持的协议内包含Http2.0时，则就会把请求升级到Http2.0阶段。
OKHttp与HttpClient类似，也是一个Http客户端，提供了对 HTTP/2 和 SPDY 的支持，并提供了连接池，GZIP 压缩和 HTTP 响应缓存功能。
OkHttp优点
（1）支持HTTP2/SPDY
（2）拥有自动维护的socket连接池，减少握手次数，减少了请求延迟，共享Socket,减少对服务器的请求次数
（3）基于Headers的缓存策略减少重复的网络请求
（4）拦截器Interceptors（AOP实现）
OkHttp功能
(1)一般的get请求、post请求
(2)基于Http的文件上传下载
(3)加载图片
(4)支持session的保持
(5)支持自签名网站https的访问，提供方法设置下证书就行
(6)支持取消某个请求