2024年Android最全迈向高阶：优秀Android程序员必知必会的网络基础(3)，2024年最新2024互联网大厂Android面经合集

最后

**要想成为高级安卓工程师，必须掌握许多基础的知识。**在工作中，这些原理可以极大的帮助我们理解技术，在面试中，更是可以帮助我们应对大厂面试官的刁难。

---

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化学习资料的朋友，可以戳这里获取

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！

**5）物理层：**这一层就是最底层了，提供二进制流传输服务，也就是也就是真正开始通过传输介质（有线、无线）开始进行数据的传输了。

所以通过上面五层的各司其职，实现物理传输介质–MAC地址–IP地址–端口号–获取到数据根据应用层协议解析数据最终实现了网络通信和数据传输。

下面会着重讲一下HTTP和TCP相关的东西，关于其他层，毕业了这么久也忘的很多，如果想更加细致具体的了解像下面三层的如路由选择算法、ARP寻址以及物理层等等还是要重新去看一下《TCP/IP详解 卷1：协议》~

4、HTTP相关

本节主要讲一些关于Http的基础知识，以及在Android中的一些实际应用和碰到的问题和解决。

4.1 正确理解HTTP的“无连接”“与无状态”

Http是无连接无状态的。

无连接并不是说不需要连接，Http协议只是一个应用层协议，最终还是要靠运输层的如TCP协议向上提供的服务进行连接。

无连接的含义是http约定了每次连接只处理一个请求，一次请求完成后就断开连接，这样主要是为了缓解服务器的压力，减小连接对服务器资源的占用。我的理解是，建立连接实际上是运输层的事，面向应用层的http来说的话，它就是无连接的，因为上层对下层无感知。

无状态的指每个请求之间都是独立的，对于之前的请求事务没有记忆的能力。所以就出现了像Cookie这种，用来保存一些状态的东西。

4.2 请求报文与响应报文

这里主要简单说一下HTTP请求报文和响应报文的格式方面的基础知识。

请求报文：

响应报文:

关于Get和Post，我们都熟知的关于Get和Post的区别大致有以下几点：

1）Get会把请求参数都拼接在url后面，最终显示在地址栏，而Post则会把请求参数数据放进请求体中，不会再地址栏显示出来；

2）传递参数的长度限制。

问题：

对于第1）点，如果是在浏览器里把隐私数据暴露在地址栏上确实不妥，但是如果是在App开发中呢，没有地址栏的概念，那么这一点是不是还会成为选择post还是get的制约条件；

对于第2）点，长度的限制应该是浏览器的限制，跟get本身无关，如果是在App开发中，这一点是否也可以忽略。

4.3 HTTP的缓存机制

之所以想介绍以下Http的缓存机制，是因为Okhttp中对于网络请求缓存这一块就是利用了Http的的缓存机制，而不是像Volley等框架那样客户端完全自己写一套缓存策略自己玩。

Http的缓存主要利用header里的两个字段来控制：即Cache-control和ETag，下面将分别来介绍。

1）Cache-control主要包含以及几个字段：

private:则只有客户端可以缓存；

public:客户端和代理服务器都可以缓存；

max-age:缓存的过期时间；

no-cache:需要使用对比缓存来验证缓存数据；

no-store:所有内存都不会进行缓存。

实际上就是在这里面设置了一个缓存策略，由服务端第一次通过header下发给客户端，可以看到：

max-age：即缓存过期的时间，则之后再次请求，如果没有超过缓存失效的时间则可以直接使用缓存；

no-cache：表示需要使用对比缓存来验证缓存数据，如果这个字段是打开的，则就算max-age缓存没有失效，则还是需要发起一次请求向服务端确认一下资源是否有更新，是否需要重新请求数据，至于怎么做对比缓存，就是下面要说的Etag的作用。如果服务端确认资源没有更新，则返回304，取本地缓存即可，如果有更新，则返回最新的资源；

no-store：这个字段打开，则不会进行缓存，也不会取缓存。

2）ETag：即用来进行对比缓存，Etag是服务端资源的一个标识码

当客户端发送第一次请求时服务端会下发当前请求资源的标识码Etag，下次再请求时，客户端则会通过header里的If-None-Match将这个标识码Etag带上，服务端将客户端传来的Etag与最新的资源Etag做对比，如果一样，则表示资源没有更新，返回304。

3）小结：

通过Cache-control和Etag的配合来实现Http的缓存机制。更多有关HTTP缓存方面的的知识，在文章《脑残式网络编程入门(三)：HTTP协议必知必会的一些知识》的相关章节做了详细的读解，可以参阅之。

4.4 HTTP的Cookie

上面说了Http协议是无状态的，而Cookie就是用来在本地缓存记住一些状态的，一个Cookie一般都包含domin(所属域)、path、Expires(过期时间)等几个属性。服务端可以通过在响应头里的set-cookies来将状态写入客户端的Cookie里。下次客户端发起请求时可以将Cookie带上。

Android开发中遇到的问题及解决：

说起Cookie，一般如果平常只是做App开发，比较不经常遇到，但是如果是涉及到WebView的需求，则有可能会遇到。

下面就说一下我在项目里遇到过的一个关于WebView Cookie的揪心往事：需求是这样的，加载的WebView中的H5页面需要是已登录状态的，所以我们需要在原生页面登录后，手动将ticket写入WebView的Cookie，之后WebView里加载的H5页面带着Cookie里的ticket给服务端验证通过就好了。

但是遇到一个问题：通过Chrome inspect调试WebView，手动写的Cookie确实是已经写进去了，但是发起请求的时候，Cookie就是没有带上，导致请求验证失败，之后通过排查，是WebView的属性默认关闭引起，通过下面的代码设置打开即可：

CookieManager cookieManager = CookieManager.getInstance(); if(Build.VERSION.SDK_INT >= Build.VERSION_CODES.LOLLIPOP) { cookieManager.setAcceptThirdPartyCookies(mWebView, true); } else{ cookieManager.setAcceptCookie(true); }

4.5 Https

我们都知道Https保证了我们数据传输的安全，Https=Http+Ssl，之所以能保证安全主要的原理就是利用了非对称加密算法，平常用的对称加密算法之所以不安全，是因为双方是用统一的密匙进行加密解密的，只要双方任意一方泄漏了密匙，那么其他人就可以利用密匙解密数据。

而非对称加密算法之所以能实现安全传输的核心精华就是：公钥加密的信息只能用私钥解开，私钥加密的信息只能被公钥解开。

1）简述非对称加密算法为什么安全：

服务端申请CA机构颁发的证书，则获取到了证书的公钥和私钥，私钥只有服务器端自己知道，而公钥可以告知其他人，如可以把公钥传给客户端，这样客户端通过服务端传来的公钥来加密自己传输的数据，而服务端利用私钥就可以解密这个数据了。由于客户端这个用公钥加密的数据只有私钥能解密，而这个私钥只有服务端有，所以数据传输就安全了。

上面只是简单说了一下非对称加密算法是如何保证数据安全的，实际上Https的工作过程远比这要复杂（篇幅限制这里就不细说了，网上有很多相关文章）：

一个是客户端还需要验证服务端传来的CA证书的合法性、有效性，因为存在传输过程CA证书被人调包的风险,涉及到客户端如何验证服务器证书的合法性的问题，保证通信双方的身份合法；

另一个是非对称算法虽然保证了数据的安全，但是效率相对于对称算法来说比较差，如何来优化，实现既保证了数据的安全，又提高了效率。

2）客户端如何验证证书的合法性：

首先CA证书一般包括以下内容：

证书的颁发机构以及版本； 证书的使用者； 证书的公钥； 证书有效时间； 证书的数字签名Hash值以及签名Hash算法（这个数字签名Hash值是用证书的私钥加密过的值）； 等等。

客户端验证服务端传过来的证书的合法性是通过：先利用获取到的公钥来解密证书中的数字签名Hash值1（因为它是利用私钥加密的嘛），然后在利用证书里的签名Hash算法生成一个Hash值2，如果两个值相等，则表示证书合法，服务器端可以被信任。

3）Android开发中遇到的问题及解决：

顺便说一个在项目开发中使用Android WebView加载公司测试服务器上网页证书过期导致网页加载不出来白屏的问题。

解决方案就是测试环境下暂时忽略SSL的报错，这样就可以把网页加载出来，当然在生产上不要这么做，一个是会有安全问题，一个是google play应该审核也不会通过。

最佳办法是重写WebViewClient的onReceivedSslError()：

@Override publicvoidonReceivedSslError(WebView view, SslErrorHandler handler, SslError error) { if(ContextHolder.sDebug) { handler.proceed(); return; } super.onReceivedSslError(view, handler, error); }

**最后：**有关HTTPS更为详细全面的知识，请深入阅读《即时通讯安全篇（七）：如果这样来理解HTTPS原理，一篇就够了》。

4.6 Http 2.0

Okhttp支持配置使用Http 2.0协议，Http2.0相对于Http1.x来说提升是巨大的，主要有以下几点。

**1）二进制格式：**http1.x是文本协议，而http2.0是二进制以帧为基本单位，是一个二进制协议，一帧中除了包含数据外同时还包含该帧的标识：Stream Identifier，即标识了该帧属于哪个request,使得网络传输变得十分灵活；

**2）多路复用：**一个很大的改进，原先http1.x一个连接一个请求的情况有比较大的局限性，也引发了很多问题，如建立多个连接的消耗以及效率问题。

http1.x为了解决效率问题，可能会尽量多的发起并发的请求去加载资源，然而浏览器对于同一域名下的并发请求有限制，而优化的手段一般是将请求的资源放到不同的域名下来突破这种限制。

而http2.0支持的多路复用可以很好的解决这个问题，多个请求共用一个TCP连接，多个请求可以同时在这个TCP连接上并发，一个是解决了建立多个TCP连接的消耗问题，一个也解决了效率的问题。

那么是什么原理支撑多个请求可以在一个TCP连接上并发呢？基本原理就是上面的二进制分帧，因为每一帧都有一个身份标识，所以多个请求的不同帧可以并发的无序发送出去，在服务端会根据每一帧的身份标识，将其整理到对应的request中。

**3）header头部压缩：**主要是通过压缩header来减少请求的大小，减少流量消耗，提高效率。因为之前存在一个问题是，每次请求都要带上header，而这个header中的数据通常是一层不变的。

4）支持服务端推送。

有关HTTP2的更多知识，请阅读《从HTTP/0.9到HTTP/2：一文读懂HTTP协议的历史演变和设计思路》。

5、TCP相关

TCP面向连接，提供可靠的数据传输。在这一层，我们通常都是通过Socket Api来操作TCP，建立连接等等。

5.1 三次握手建立连接

第一次：发送SNY=1表示此次握手是请求建立连接的，然后seq生成一个客户端的随机数X

第二次：发送SNY=1,ACK=1表示是回复请求建立连接的，然后ack=客户端的seq+1（这样客户端收到后就能确认是之前想要连接的那个服务端），然后把服务端也生成一个代表自己的随机数seq=Y发给客户端。

第三次：ACK=1。 seq=客户端随机数+1，ack=服务端随机数+1（这样服务端就知道是刚刚那个客户端了）

为什么建立连接需要三次握手？

首先非常明确的是两次握手是最基本的，第一次握手，C端发了个连接请求消息到S端，S端收到后S端就知道自己与C端是可以连接成功的，但是C端此时并不知道S端是否接收到这个消息，所以S端接收到消息后得应答，C端得到S端的回复后，才能确定自己与S端是可以连接上的，这就是第二次握手。

C端只有确定了自己能与S端连接上才能开始发数据。所以两次握手肯定是最基本的。

那么为什么需要第三次握手呢？假设一下如果没有第三次握手，而是两次握手后我们就认为连接建立，那么会发生什么？

第三次握手是为了防止已经失效的连接请求报文段突然又传到服务端，因而产生错误。

具体情况就是：

C端发出去的第一个网络连接请求由于某些原因在网络节点中滞留了，导致延迟，直到连接释放的某个时间点才到达S端，这是一个早已失效的报文，但是此时S端仍然认为这是C端的建立连接请求第一次握手，于是S端回应了C端，第二次握手。

如果只有两次握手，那么到这里，连接就建立了，但是此时C端并没有任何数据要发送，而S端就会傻傻的等待着，造成很大的资源浪费。所以需要第三次握手，只有C端再次回应一下，就可以避免这种情况。

要想深刻理解TCP三次握手，请不要错过以下文章：

《TCP/IP详解 - 第18章·TCP连接的建立与终止》

《通俗易懂-深入理解TCP协议（上）：理论基础》

《理论经典：TCP协议的3次握手与4次挥手过程详解》

《理论联系实际：Wireshark抓包分析TCP 3次握手、4次挥手过程》

《脑残式网络编程入门(一)：跟着动画来学TCP三次握手和四次挥手》

5.2 四次挥手断开连接

[图片上传中…(image-80d187-1595339200909-4)]

经过上面的建立连接图的解析，这个图应该不难看懂。

**这里主要有一个问题：**为什么比建立连接时多了一次挥手？

可以看到这里服务端的ACK(回复客户端)和FIN(终止)消息并不是同时发出的，而是先ACK，然后再FIN，这也很好理解，当客户端要求断开连接时，此时服务端可能还有未发送完的数据，所以先ACK，然后等数据发送完再FIN。这样就变成了四次握手了。

尾声

最后，我再重复一次，如果你想成为一个优秀的 Android 开发人员，请集中精力，对基础和重要的事情做深度研究。

对于很多初中级Android工程师而言，想要提升技能，往往是自己摸索成长，不成体系的学习效果低效漫长且无助。 整理的这些架构技术希望对Android开发的朋友们有所参考以及少走弯路，本文的重点是你有没有收获与成长，其余的都不重要，希望读者们能谨记这一点。

最后想要拿高薪实现技术提升薪水得到质的飞跃。最快捷的方式，就是有人可以带着你一起分析，这样学习起来最为高效，所以为了大家能够顺利进阶中高级、架构师，我特地为大家准备了一套高手学习的源码和框架视频等精品Android架构师教程，保证你学了以后保证薪资上升一个台阶。

当你有了学习线路，学习哪些内容，也知道以后的路怎么走了，理论看多了总要实践的。

进阶学习视频

附上：我们之前因为秋招收集的二十套一二线互联网公司Android面试真题 （含BAT、小米、华为、美团、滴滴）和我自己整理Android复习笔记（包含Android基础知识点、Android扩展知识点、Android源码解析、设计模式汇总、Gradle知识点、常见算法题汇总。）

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化学习资料的朋友，可以戳这里获取

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！

3)]

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化学习资料的朋友，可以戳这里获取

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！