Android 面试准备进行曲(网络基础篇） v1.1
@TOC
update time 2019年09月19日14:02:34
CSDN地址 （尴尬 简书暂时还没有学会整目录 -，-）
前言
在总结完 前两章的Android 基础知识后，我发现自己的Java 基础方面相当的薄弱（当然这个是我一直都有的软肋，这次暴漏的更加明显）所以临时总结 添加一篇基础知识，包含的内容：常问的基础面试题+重点知识点。写完这一篇文章后，后续会主要总结和阅读 我经常使用的第三方工具 的源码解析 例如：Okhttp ，rxjava 等的简单源码理解和剖析。本人三年小白，还在不断摸索中成长，文章有不对的地方劳烦指出，本人将改正学习，加油
重点顺序 参考博客 厘米大佬 nb
网络基础
网络协议的体系结构
物理层
数据链路层：逻辑链路控制LLC、媒体接入控制MAC
网络层：IP协议、地址解析协议ARP、逆地址解析协议RARP、因特网控制报文协议ICMP
传输层：传输控制协议TCP、用户数据报协议UDP
应用层：文件传输协议FTP、远程登录协议TELNET、超文本传输协议HTTP、域名系统DNS、简单邮件协议SMTP、简单网络管理协议SNMP
在这里插入图片描述
TCP和UDP
-
TCP传输控制协议：面向连接；使用全双工的可靠信道；提供可靠的服务，即无差错、不丢失、不重复且按序到达；拥塞控制、流量控制、超时重发、丢弃重复数据等等可靠性检测手段；面向字节流；每条TCP连接只能是点到点的；用于传输可靠性要求高的数据，协议上来说没有长度限制（但是使用中还是不建议过长数据传输）
-
UDP用户数据报协议：UDP 本身不提供确认，序列号，超时重传等机制，有长度限制，无连接；使用不可靠信道；尽最大努力交付，即不保证可靠交付；无拥塞控制等；面向报文；支持一对一、一对多、多对一和多对多的交互通信；用于传输可靠性要求不高的数据（举例场景：包总量较少的通信（DNS、SNMP），即时通信，广播、多播）
TCP特性
- TCP 提供一种面向连接的、可靠的字节流服务
- 仅有两方进行彼此通信。不能广播和多播
- TCP 使用校验和，确认和重传机制来保证可靠传输
- TCP 给数据分节进行排序，并使用累积确认保证数据的顺序不变和非重复
- TCP 使用滑动窗口机制来实现流量控制，通过动态改变窗口的大小进行拥塞控制
注意：TCP 并不能保证数据一定会被对方接收到。TCP 能够做到的是，如果有可能，就把数据递送到接收方，否则就（通过放弃重传并且中断连接这一手段）通知用户。因此它所能提供的是数据的可靠递送或故障的可靠通知。
拥塞控制和流量控制
- 拥塞控制：对网络中的路由和链路传输进行速度限制，避免网络过载；包含四个过程：慢启动、拥塞避免、快重传和快恢复
- 流量控制 ：对点和点/发送方和接收方之间进行速度匹配，由于接收方的应用程序读取速度不一定很迅速，加上缓存有限，因此需要避免发送速度过快；相关技术：TCP滑动窗口、回退N针协议
TCP 握手
参考GitBook
建立一个 TCP 连接时，需要客户端和服务器总共发送3个包。三次握手的目的是连接服务器指定端口，建立 TCP 连接，并同步连接双方的序列号和确认号，交换 TCP 窗口大小信息。
第一次握手(SYN=1, seq=x):
客户端发送一个 TCP 的 SYN 标志位置1的包，指明客户端打算连接的服务器的端口，以及初始序号 X,保存在包头的序列号(Sequence Number)字段里。
发送完毕后，客户端进入 SYN_SEND 状态。
第二次握手(SYN=1, ACK=1, seq=y, ACKnum=x+1):
服务器发回确认包(ACK)应答。即 SYN 标志位和 ACK 标志位均为1。服务器端选择自己 ISN 序列号，放到 Seq 域里，同时将确认序号(Acknowledgement Number)设置为客户的 ISN 加1，即X+1。 发送完毕后，服务器端进入 SYN_RCVD 状态。
第三次握手(ACK=1，ACKnum=y+1)
客户端再次发送确认包(ACK)，SYN 标志位为0，ACK 标志位为1，并且把服务器发来 ACK 的序号字段+1，放在确定字段中发送给对方，并且在数据段放写ISN的+1
发送完毕后，客户端进入 ESTABLISHED 状态，当服务器端接收到这个包时，也进入 ESTABLISHED 状态，TCP 握手结束。
在这里插入图片描述
TCP 挥手
第一次挥手(FIN=1，seq=x)
假设客户端想要关闭连接，客户端发送一个 FIN 标志位置为1的包，表示自己已经没有数据可以发送了，但是仍然可以接受数据。
发送完毕后，客户端进入 FIN_WAIT_1 状态。
第二次挥手(ACK=1，ACKnum=x+1)
服务器端确认客户端的 FIN 包，发送一个确认包，表明自己接受到了客户端关闭连接的请求，但还没有准备好关闭连接。
发送完毕后，服务器端进入 CLOSE_WAIT 状态，客户端接收到这个确认包之后，进入 FIN_WAIT_2 状态，等待服务器端关闭连接。
第三次挥手(FIN=1，seq=y)
服务器端准备好关闭连接时，向客户端发送结束连接请求，FIN 置为1。
发送完毕后，服务器端进入 LAST_ACK 状态，等待来自客户端的最后一个ACK。
第四次挥手(ACK=1，ACKnum=y+1)
客户端接收到来自服务器端的关闭请求，发送一个确认包，并进入 TIME_WAIT状态，等待可能出现的要求重传的 ACK 包。
服务器端接收到这个确认包之后，关闭连接，进入 CLOSED 状态。
客户端等待了某个固定时间（两个最大段生命周期，2MSL，2 Maximum Segment Lifetime）之后，没有收到服务器端的 ACK ，认为服务器端已经正常关闭连接，于是自己也关闭连接，进入 CLOSED 状态。
在这里插入图片描述
HTTP
HTTP 协议构建于 TCP/IP 协议之上，是一个应用层协议，默认端口号是 80，HTTP 是无连接无状态的。
HTTP 定义了与服务器交互的不同方法，最基本的方法有4种，分别是GET，POST，PUT，DELETE。URL全称是资源描述符，对应着对这个资源的查，增，改，删4个操作。
重点说下 GET/POST :
-
GET：当客户端要从服务器中读取某个资源时使用GET；一般用于获取/查询资源信息；GET参数通过URL传递，传递的参数是有长度限制，不能用来传递敏感信息
-
POST：当客户端给服务器提供信息较多时可以使用POST；POST会附带用户数据，一般用于更新资源信息；POST将请求参数封装在HTTP 请求数据中，可以传输大量数据，传参方式比GET更安全
状态码：
HTTP 响应与 HTTP 请求相似，HTTP响应也由3个部分构成，分别是：
-
状态行
响应头(Response Header)
响应正文
状态行由协议版本、数字形式的状态代码、及相应的状态描述，各元素之间以空格分隔。 -
常见的状态码有如下几种：
1xx：表示服务器已接收了客户端请求，客户端可继续发送请求
2xx：表示服务器已成功接收到请求并进行处理
3xx：表示服务器要求客户端重定向
4xx：表示客户端的请求有非法内容
400 Bad Request：表示客户端请求有语法错误，不能被服务器所理解
401 Unauthonzed：表示请求未经授权，该状态代码必须与 WWW-Authenticate 报头域一起使用
403 Forbidden：表示服务器收到请求，但是拒绝提供服务，通常会在响应正文中给出不提供服务的原因
404 Not Found：请求的资源不存在，例如，输入了错误的URL
5xx：表示服务器未能正常处理客户端的请求而出现意外错误
500 Internal Server Error：表示服务器发生不可预期的错误，导致无法完成客户端的请求
503 Service Unavailable：表示服务器当前不能够处理客户端的请求，在一段时间之后，服务器可能会恢复正常
HTTP 发展之路
- HTTP1.0默认使用短连接，HTTP1.1开始默认使用长连接
HTTP1.1增加更多的请求头和响应头来改进和扩充HTTP1.0的功能，比如身份认证、状态管理和Cache缓存等 - HTTP2.0的协议解析决定采用二进制格式，实现方便且健壮，不同于HTTP1.x的解析是基于文本，HTTP2.0 可以主动服务端推送：
HTTP 和 HTTPS区别
-
HTTP（超文本传输协议）：运行在TCP之上；传输的内容是明文；端口是80
-
HTTPS（安全为目标的HTTP）：运行在SSL/TLS之上，SSL/TLS运行在TCP之上；传输的内容经过加密；端口是443
访问URL 过程
在浏览器地址栏键入URL后：
- 浏览器向DNS服务器请求解析该URL中的域名所对应的IP地址
- 解析出IP地址后，根据该IP地址和默认端口80，和服务器建立TCP连接
- 浏览器发出读取文件的HTTP请求，该请求报文作为TCP三次握手的第三个报文的数据发送给服务器
- 服务器对浏览器请求作出响应，并把对应的html文本发送给浏览器
- 释放TCP连接，若connection模式为close，则服务器主动关闭TCP连接，客户端被动关闭连接，释放TCP连接；若connection模式为keepalive，则该连接会保持一段时间，在该时间内可以继续接收请求
- 客户端将服务器响应的html文本解析并显示
