无法启动APK安装也，报异常FileUriExposedException

先记录一个问题：

无法启动APK安装，报异常FileUriExposedException

无法打开APK安装页，报异常FileUriExposedException，

https://juejin.im/entry/58e4643db123db15eb79a902

TCP相关问题整理

• TCP为什么是四次挥手，

  关于四次挥手：首先TCP连接是双向传输的对等模式，当其中一方主动发起释放连接以后，接收方收到释放连接报文后会通知高层应用进程当前这个方向的连接释放，然后进入的是半关闭状态，这个时候相反方向还是能够发送数据的，当两个相反方向都分别进行一次主动发起释放和确认才真正地断开连接，总共是四次挥手。

  FIN报文段表示对方不再发送数据，但是自己可以发送数据给对方，对方也还有接收能力；己方如果要发起释放连接需要高层应用的决定。

• TIME-WAIT的作用

  四次挥手中TIME-WAIT状态下，客户端会设置一个时间等待计时器2MSL，因为最后一个ACK报文段在传输过程中可能出现滞留或者丢失，无法到达服务器端，服务器端就会重传FIN ACK报文段。2MSL时间等待的作用就是等待服务端的重传FIN ACK报文段，然后恢复确认，正常关闭服务器端向客户端这个方向的连接。

• TCP四次挥手，第四次挥手时一直丢包了怎么办？

  进入异常关闭情况。（不确定，可能会有个重发的次数限制，或者跟TCP连接当中保活计时器有关？）

• 为什么是三次握手

  • 三次握手是指的最少三次握手，这个过程可以确定双方接收发送能力正常，之后能够正常通信：每一次发送报文段又收到确认报文段的一方，就能够直到自己的接收能力是正常的，对方的发送能力也是正常的。

  • 防止因网络滞留已经失效的连接请求报文到达接收方，使接收方误认为对方要建立连接，所以第三次握手的报文就是为了确认连接请求报文的有效性。

  • 以尽可能小的代价同步双方的初始序列号建立起连接。具体来说第一次握手的过程，发送方会选择一个随机的序列号作为自己的初始序列号发送给接收方，接收方收到后并不知道这个序列号是不是对方此次连接的初始序列号，于是会进行确认并且携带自己的初始序列号，发送方收到之后可以知道接受方的初始确认号，因为这是一个确认报文，所以还可以知道接收方已经收到了它的初始序列号，但是此时接收方还是不能够判断自己收到的初始确认号是不是本次连接的，于是发送方会发送第三次报文给接收方，接收方收到后就能够确定自己收到的初始序列号是本次连接的，这样经过三次握手通信双方都知道了各自的初始序列号，因为初始序列号是随机生成的，在有些操作系统的实现是每4微秒增加1，需要大概4小时的时间才会重复，这个时间远远大于报文段在网络中的最长寿命，因此每一个连接都有独一无二的初始序列号，知道了对方的初始序列号就能判断接收到的是不是一个合法的报文段，从而实现确认和重传等操作，另外初始报文的获取是随机的，黑客很难伪造一个报文段来干扰这次连接。

• tcp如果没有第三次握手会怎么样?

  如果是两次握手可能会出现这样的问题，客户端发送的一个连接请求报文可能在网络中延迟，直到客户端和服务端的连接已经释放后才到达服务端，服务端接受到这个连接请求报文后会进行确认，假如没有第三次握手，服务端就以为连接建立了，而客户端此时并没有发送建立连接的请求，所以不会管收到的确认报文，这种情况下客户端认为没有建立连接，服务端却认为建立了连接等待数据的传送会导致服务端资源的浪费。这种情况出现的问题是，TCP的一端无法确认自己收到的报文段是不是合法的。

• tcp可靠传输的实现（累积确认&超时重传）

  TCP的可靠传输是通过滑动窗口协议实现的，通信双方各自拥有发送缓存和接收缓存以及发送窗口和接收窗口。通信前双方会协商发送窗口和接收窗口的值，然后发送方只会发送发送窗口范围内的数据，而且接收方会对接收窗口内收到的数据进行累积确认，对按序到达的数据的最后一个字节序号返回确认，或者是采用选择确认的方式通知发送方哪些数据没有收到。

  但是这个过程当中关于可靠传输最重要的一点就是超时重传的机制，发送方在没有收到接收方确认的情况下，不可能去猜测数据的下落，而是会在超时计时器的控制下重传数据，直到收到确认。

• TCP与UDP属于那一层，以及区别？

  TCP传输控制协议与UDP用户数据报协议都是运输层的协议。

  区别：

  • 面向连接：TCP提供面向连接的服务，传送数据之前必须要先建立连接，数据传送结束后要释放连接；而UDP在传送数据之前不需要建立连接。

  • 可靠传输：TCP协议保证数据按序发送，按序到达，并且提供了超时重传来保证可靠性；但是UDP不保证按序到达，甚至不保证到达，只是尽最大努力交付。

  • 流量控制与拥塞控制：TCP都有；但是UDP没有，网络拥堵也不会影响发送端发送的速率。

  • 连接的端：TCP是一对一连接，不提供广播或者多播服务；而UDP可以支持一对一、一对多、多对多的通信。

  • 字节流or报文：TCP面向的是字节流的服务，而UDP面向的是报文的服务。

  • 消耗资源：由于TCP要提供面向连接的可靠传输，增加了许多开销，比如确认、流量控制、计时器以及连接管理，所以协议数据单元首部就需要至少20个字节，如果加上可选项就更多了，另外还会占用许多处理机资源；而UDP首部只需要8个字节。

• TCP三次握手，四次挥手，两个栈模拟队列（这里应该是两个问题吧）

  • 半连接队列&全连接队列：服务器第一次收到客户端的 SYN 报文段之后，就会处于 SYN_RCVD 状态，这时双方还没有完全建立其连接，服务器就会把这种状态下请求连接放在一个队列里，我们把这种队列称之为半连接队列。同时还有一个全连接队列，就是已经完成三次握手，建立起连接的就会放在全连接队列中。如果队列满了就有可能会出现丢包现象。另外关于SYN-ACK 重传次数的问题：服务器发送完SYN-ACK包，如果未收到客户确认包，服务器进行首次重传，等待一段时间仍未收到客户确认包，进行第二次重传。如果重传次数超过系统规定的最大重传次数，系统将该连接信息从半连接队列中删除。 注意，每次重传等待的时间不一定相同，一般会是指数增长，例如间隔时间为 1s，2s，4s，8s......

  关于TCP 半连接队列和全连接队列

• TCP拥塞控制机制?

  首先，路由器因无法处理高速率到达的流量而被迫丢弃数据信息的现象称为拥塞。

  所以拥塞控制就是为了防止网络因为大规模的通信负载而瘫痪，在网络即将进入拥塞状态时减缓TCP传输。TCP使用滑动窗口机制发送和接收数据，发送速率的控制是通过调节发送窗口大小实现的，但是发送窗口大小只取决于接收方接收数据的能力。而拥塞控制需要考虑网络的拥塞状况，因此引入了一个拥塞窗口，TCP发送窗口要取通知窗口(awnd) 和拥塞窗口(cwnd)两者的最小值。拥塞窗口取决于网络的拥塞程度，而只要网络没有出现拥塞，拥塞窗口就可以增大一些，以提高网络利用率；相反就要减小拥塞窗口，减少注入网络的分组数目，缓解拥塞。

• 拥塞控制慢开始算法？

  拥塞窗口取决于网络的拥塞程度，而只要网络没有出现拥塞，拥塞窗口就可以增大一些，以提高网络利用率；相反就要减小拥塞窗口，减少注入网络的分组数目，缓解拥塞。拥塞窗口的以报文段个数为单位。

  主机开始发送数据时先探测网络情况，由小到大地增大发送窗口。拥塞窗口没有到达慢开始门限值的时候每收到一个确认报文段就把拥塞窗口的值加一，是一个加倍增长的特点；而如果到达了慢开始门限值后就开始采用拥塞避免算法，拥塞窗口的大小开始按加法增大，增长速率会缓慢很多，使网络不容易出现拥塞。当出现超时以后，发送方判断是出现了网络拥塞，会重新设置拥塞窗口大小，再从慢开始逐渐增大窗口值，慢开始门限值会设置的比之前要小。

• Java中server端怎么实现？

  在 Java 的 SDK 中，socket 的共有两个接口：用于监听客户连接的 ServerSocket 和用于通信的 Socket。如果使用的是 UNIX/Linux 系统的 API，这个过程就是：首先，我们创建 ServerSocket 后，内核会创建一个 socket。这个 socket 既可以拿来监听客户连接，也可以连接远端的服务。由于 ServerSocket 是用来监听客户连接的，紧接着它就会对内核创建的这个 socket 调用 listen 函数。这样一来，这个 socket 就成了所谓的 listening socket，它开始监听客户的连接。

  接下来，我们的客户端创建一个 Socket，同样的，内核也创建一个 socket 实例。内核创建的这个 socket 跟 ServerSocket 一开始创建的那个没有什么区别。不同的是，接下来 Socket 会对它执行 connect，发起对服务端的连接。socket API 其实是 TCP 层的封装，所以 connect 后，内核会发送一个 SYN 给服务端。

  现在，我们切换角色到服务端。服务端的主机在收到这个 SYN 后，会创建一个新的 socket，这个新创建的 socket 跟客户端继续执行三次握手过程。

  三次握手完成后，我们执行的 serverSocket.accept() 会返回一个 Socket 实例，这个 socket 就是上一步内核自动帮我们创建的。

  所以说，在一个客户端连接的情况下，其实有 3 个 socket，客户端一个，服务端有两个。

• 画TCP三次握手和四次挥手的过程？

• TCP 的首部?