Android 基础之网络

2019-02-13 本文已影响2人 Kevin_小飞象

HTTP

Http报文

http报文可以分为请求报文和响应报文。
请求报文格式：

<method> <request-url> <version>
<headers>

<entity-body>

响应报文格式：

<version> <status> <reason-phrase>
<headers>

<entity-body>

解释下各个标签:

<method> 指请求方法，常用的主要是Get、 Post、Head 还有其他一些我们这里就不说了，有兴趣的可以自己查阅一下

<version> 指协议版本，现在通常都是Http/1.1了

<request-url> 请求地址

<status> 指响应状态码， 我们熟悉的200、404等等

<reason-phrase> 原因短语，200 OK 、404 Not Found 这种后面的描述就是原因短语，通常不必太关注。

method

请求方法最常用的有 Get 和 Post 两种，面试时也常常会问到这两者有什么区别?

两个方法之间在传输形式上有一些区别。
通过 Get 方法发起请求时，会将请求参数拼接在request-url尾部，格式是url?param1=xxx&param2=xxx&[…]。这样传输参数会使得参数都暴露在地址栏中。
通过 Post 方法发起的请求是将参数放在请求体中的，所以不会有 Get 参数的这些问题。
方法本身的语义区别。
Get 方法通常是指从服务器获取某个 URL 资源，其行为可以看作是一个读操作，对同一个 URL 进行多次 Get 并不会对服务器产生什么影响。
Post 方法通常是对某个 URL 进行添加、修改，例如一个表单提交，通常会往服务器插入一条记录。多次 Post 请求可能导致服务器的数据库中添加了多条记录。

状态码

常见的状态码：
200 OK 请求成功，实体包含请求的资源
206 Partial Content 成功执行一个部分请求。这个在用于断点续传时会涉及到。
301 Moved Permanent 请求的URL被移除了，通常会在Location首部中包含新的URL用于重定向。
304 Not Modified 条件请求进行再验证，资源未改变。
404 Not Found 资源不存在
500 HTTP Version not supported 服务器不支持请求的HTTP协议的版本，无法完成处理

Http缓存

当我们发起一个 http 请求后，服务器返回所请求的资源，这时我们可以将该资源的副本存储在本地，这样当再次对该 url 资源发起请求时，我们能快速的从本地存储设备中获取到该 url 资源，这就是所谓的缓存。缓存既可以节约不必要的网络宽带，又能迅速对http请求做出响应。
当我们发起一个请求时，我们需要先对缓存的资源进行判断，看看究竟我们是否可以直接使用该缓存资源，这个就叫做 新鲜度检测。
如果发现该缓存资源已经超过了一定的时间，我们再次发起请求时不会直接将缓存资源返回，而是先去服务器查看该资源是否已经改变，这个就叫做 再验证。
如果服务器发现对应的 url 资源并没有发生变化，则会返回 304 Not Modified，并且不再返回对应的实体。这称之为 再验证命中。相反如果再验证未命中，则返回 200 OK，并将改变后的 url 资源返回，此时缓存可以更新以待之后请求。
具体的实现方式：

1. 新鲜度检测  
我们需要通过检测资源是否超过一定的时间，来判断缓存资源是否新鲜可用。那么这个一定的时间怎么决定呢？
其实是由服务器通过在响应报文中增加 Cache-Control:max-age，或是 Expire 这两个首部来实现的。
值得注意的是 Cache-Control 是 http1.1 的协议规范，通常是接相对的时间，即多少秒以后，
需要结合 last-modified 这个首部计算出绝对时间。而 Expire 是 http1.0 的规范，后面接一个绝对时间。

2. 再验证  
如果通过新鲜度检测发现需要请求服务器进行再验证，那么我们至少需要告诉服务器，我们已经缓存了一个什么样的资源了，
然后服务器来判断这个缓存资源到底是不是与当前的资源一致。逻辑是这样没错。那怎么告诉服务器我当前已经有一个备用的缓存资源了呢？
我们可以采用一种称之为条件请求的方式实现再验证。

3. Http 定义了5个首部用于条件请求:  
If-Modified-Since   
If-None-Match  
If-Unmodified-Since  
If-Range  
If-Match

Https

简单的说 Http + 加密 + 认证 + 完整性保护 = Https。
在一些需要保证安全性的场景下，比如涉及到银行账户的请求时，Http无法抵御这些攻击。
Https则可以通过增加的 SSL \ TLS ，支持对于通信内容的加密，以及对通信双方的身份进行验证。

Https的加密

目前 Https 加密的方式主要有两类：
1.对称秘钥加密
2.非对称秘钥加密

对称秘钥加密是指加密与解密过程使用同一把秘钥。这种方式的优点是处理速度快，但是如何安全的从一方将秘钥传递到通信的另一方是一个问题。

非对称秘钥加密是指加密与解密使用两把不同的秘钥。这两把秘钥，一把叫公开秘钥，可以随意对外公开。一把叫私有秘钥，只用于本身持有。得到公开秘钥的客户端可以使用公开秘钥对传输内容进行加密，而只有私有秘钥持有者本身可以对公开秘钥加密的内容进行解密。这种方式克服了秘钥交换的问题，但是相对于对称秘钥加密的方式，处理速度较慢。

SSL \ TLS 的加密方式则是结合了两种加密方式的优点。首先采用非对称秘钥加密，将一个对称秘钥使用公开秘钥加密后传输到对方。对方使用私有秘钥解密，得到传输的对称秘钥。之后双方再使用对称秘钥进行通信。这样即解决了对称秘钥加密的秘钥传输问题，又利用了对称秘钥的高效率来进行通信内容的加密与解密。

Https的认证

SSL\TLS 采用的混合加密的方式还是存在一个问题，即怎么样确保用于加密的公开秘钥确实是所期望的服务器所分发的呢？也许在收到公开秘钥时，这个公开秘钥已经被别人篡改了。因此，我们还需要对这个秘钥进行认证的能力，以确保我们通信的对方是我们所期望的对象。

目前的做法是使用由数字证书认证机构颁发的公开秘钥证书。服务器的运营人员可以向认证机构提出公开秘钥申请。认证机构在审核之后，会将公开秘钥与共钥证书绑定。服务器就可以将这个共钥证书下发给客户端，客户端在收到证书后，使用认证机构的公开秘钥进行验证。一旦验证成功，即可知道这个秘钥是可以信任的秘钥。

TCP/IP 协议

IP

IP 协议提供了主机和主机间的通信。为了完成不同主机间的通信，我们需要某种方式来唯一标识一台主机，这个标识，就是著名的IP地址。通过IP地址，IP 协议就能够帮我们把一个数据包发送给对方。

TCP

TCP 协议在 IP 协议提供的主机间通信功能的基础上，完成这两个主机上进程对进程的通信。
为了标识数据属于哪个进程，我们给需要进行 TCP 通信的进程分配一个唯一的数字来标识它。这个数字，就是我们常说的端口号。

TCP连接的建立（三次握手）

三次握手

TCP 服务器进程先创建传输控制块 TCB，时刻准备接受客户进程的连接请求，此时服务器就进入了 LISTEN（监听）状态；
TCP 客户进程也是先创建传输控制块 TCB，然后向服务器发出连接请求报文，这是报文首部中的同部位 SYN=1，同时选择一个初始序列号 seq=x ，此时，TCP 客户端进程进入了 SYN-SENT（同步已发送状态）状态。TCP 规定，SYN 报文段（SYN=1的报文段）不能携带数据，但需要消耗掉一个序号。
TCP 服务器收到请求报文后，如果同意连接，则发出确认报文。确认报文中应该 ACK=1，SYN=1，确认号是 ack=x+1，同时也要为自己初始化一个序列号 seq=y，此时，TCP 服务器进程进入了 SYN-RCVD（同步收到）状态。这个报文也不能携带数据，但是同样要消耗一个序号。
TCP 客户进程收到确认后，还要向服务器给出确认。确认报文的 ACK=1，ack=y+1，自己的序列号 seq=x+1，此时，TCP 连接建立，客户端进入 ESTABLISHED（已建立连接）状态。TCP规定，ACK 报文段可以携带数据，但是如果不携带数据则不消耗序号。
当服务器收到客户端的确认后也进入 ESTABLISHED 状态，此后双方就可以开始通信了。

TCP连接的释放（四次挥手）

四次挥手

客户端进程发出连接释放报文，并且停止发送数据。释放数据报文首部，FIN=1，其序列号为seq=u（等于前面已经传送过来的数据的最后一个字节的序号加1），此时，客户端进入 FIN-WAIT-1（终止等待1）状态。 TCP 规定，FIN报文段即使不携带数据，也要消耗一个序号。
服务器收到连接释放报文，发出确认报文，ACK=1，ack=u+1，并且带上自己的序列号seq=v，此时，服务端就进入了 CLOSE-WAIT（关闭等待）状态。TCP 服务器通知高层的应用进程，客户端向服务器的方向就释放了，这时候处于半关闭状态，即客户端已经没有数据要发送了，但是服务器若发送数据，客户端依然要接受。这个状态还要持续一段时间，也就是整个 CLOSE-WAIT 状态持续的时间。
客户端收到服务器的确认请求后，此时，客户端就进入 FIN-WAIT-2（终止等待2）状态，等待服务器发送连接释放报文（在这之前还需要接受服务器发送的最后的数据）。
服务器将最后的数据发送完毕后，就向客户端发送连接释放报文，FIN=1，ack=u+1，由于在半关闭状态，服务器很可能又发送了一些数据，假定此时的序列号为 seq=w，此时，服务器就进入了 LAST-ACK（最后确认）状态，等待客户端的确认。
客户端收到服务器的连接释放报文后，必须发出确认，ACK=1，ack=w+1，而自己的序列号是seq=u+1，此时，客户端就进入了 TIME-WAIT（时间等待）状态。注意此时 TCP 连接还没有释放，必须经过 2∗∗MSL（最长报文段寿命）的时间后，当客户端撤销相应的 TCB 后，才进入 CLOSED 状态。
服务器只要收到了客户端发出的确认，立即进入 CLOSED 状态。同样，撤销 TCB 后，就结束了这次的 TCP 连接。可以看到，服务器结束 TCP 连接的时间要比客户端早一些。

常见面试题

为什么TCP客户端最后还要发送一次确认呢？

主要防止已经失效的连接请求报文突然又传送到了服务器，从而产生错误。

如果使用的是两次握手建立连接，假设有这样一种场景，客户端发送了第一个请求连接并且没有丢失，
只是因为在网络结点中滞留的时间太长了，由于TCP的客户端迟迟没有收到确认报文，以为服务器没有收到，
此时重新向服务器发送这条报文，此后客户端和服务器经过两次握手完成连接，传输数据，然后关闭连接。
此时此前滞留的那一次请求连接，网络通畅了到达了服务器，这个报文本该是失效的，
但是，两次握手的机制将会让客户端和服务器再次建立连接，这将导致不必要的错误和资源的浪费。

如果采用的是三次握手，就算是那一次失效的报文传送过来了，服务端接受到了那条失效报文并且回复了确认报文，
但是客户端不会再次发出确认。由于服务器收不到确认，就知道客户端并没有请求连接。

为什么客户端最后还要等待2MSL？

MSL（Maximum Segment Lifetime），TCP允许不同的实现可以设置不同的MSL值。

第一，保证客户端发送的最后一个ACK报文能够到达服务器，因为这个ACK报文可能丢失，站在服务器的角度看来，
我已经发送了FIN+ACK报文请求断开了，客户端还没有给我回应，应该是我发送的请求断开报文它没有收到，
于是服务器又会重新发送一次，而客户端就能在这个2MSL时间段内收到这个重传的报文，接着给出回应报文，并且会重启2MSL计时器。

第二，防止类似与“三次握手”中提到了的“已经失效的连接请求报文段”出现在本连接中。客户端发送完最后一个确认报文后，
在这个2MSL时间中，就可以使本连接持续的时间内所产生的所有报文段都从网络中消失。这样新的连接中不会出现旧连接的请求报文。

为什么建立连接是三次握手，关闭连接确是四次挥手呢？

建立连接的时候， 服务器在LISTEN状态下，收到建立连接请求的SYN报文后，把ACK和SYN放在一个报文里发送给客户端。 
而关闭连接时，服务器收到对方的FIN报文时，仅仅表示对方不再发送数据了但是还能接收数据，而自己也未必全部数据都发送给对方了，
所以己方可以立即关闭，也可以发送一些数据给对方后，再发送FIN报文给对方来表示同意现在关闭连接，
因此，己方ACK和FIN一般都会分开发送，从而导致多了一次。