Android之 网络基础

一、网路基础知识

1.1、域名解析

1.1.1 域名与Ip地址

（1）Ip地址（192.168.1.101）：ip地址是一个32位（4字节）的二进制数（IPV4）,常见格式为：192.168.1.101.IP地址是IP协议移动的一种统一的地址格式，为互联网上每一个网络和每一台主机分配一个逻辑地址.
IPV4与IPV6的区别：IPv4 使用32位（4字节）地址，因此只有 4,294,967,296 个，但随着联网设备的增加，这些地址显然是不够用的，所以需要新的协议和更多的地址。IPv6 便是这个新的协议，IPV6有128位（8字节）地址，有2^128-1个地址，IPv6 的目的皆在解决 IPv4 枯竭的问题。

（2）域名（www.baidu.com）：ip地址与域名是一对多的关系。一个ip地址可以对应多个域名，但是一个域名只有一个ip地址。ip地址是数字组成的，不方便记忆，所以有了域名。

1.1.2、域名解析 DNS

本质：
用于TCP/IP应用程序的数据库，该数据库中记录了域名和IP的对应关系，同时也是一种用于客户端和服务端通讯的应用层的计算机网络协议。
作用：
机器之间只能互相认识IP地址，它们之间的转换工作称为域名解析，域名解析需要由专门的域名解析服务器来完成，DNS就是进行域名解析的服务器。域名的最终指向是IP。将主机名和域名转换为IP地址。（域名：www.qq.com->119.147.15.13）。

1.1.3、一次请求域名解析过程

迭代查询（服务端）和递归查询（客户端）（区别：递归是查询者变化，迭代是查询者不变）
以查询 zh.wikipedia.org 为例：

• 输入域名"zh.wikipedia.org"，操作系统会先检查自己的本地hosts文件是否有这个网址映射关系。如果hosts没有这个域名的映射，则查询本地DNS解析器缓存。如果hosts与本地DNS服务器缓存都没有相应的网址映射关系，首先会找TCP/IP参数中设置的首选DNS服务器。
• 客户端发送查询报文"query zh.wikipedia.org"至DNS服务器，DNS服务器首先检查自身缓存，如果存在记录则直接返回结果。
• 如果记录老化或不存在，则：
  （1）DNS服务器向根域名服务器发送查询报文"query zh.wikipedia.org"，根域名服务器返回顶级域.org 的权威域名服务器地址。
  （2）DNS服务器向 .org 域的权威域名服务器发送查询报文"query zh.wikipedia.org"，得到二级域.wikipedia.org 的权威域名服务器地址。
  （3）DNS服务器向 .wikipedia.org 域的权威域名服务器发送查询报文"query zh.wikipedia.org"，得到主机 zh 的A记录，存入自身缓存并返回给客户端

1.1.4 以Chrome浏览器为例，Chrome解析域名对应的IP地址

• Chrome浏览器会首先搜索浏览器自身的DNS缓存（可以使用 chrome://net-internals/#dns 来进行查看），浏览器自身的DNS缓存有效期比较短，且容纳有限，大概是1000条。如果自身的缓存中存在blog.csdn.net 对应的IP地址并且没有过期，则解析成功。
• 如果（1）中未找到，那么Chrome会搜索操作系统自身的DNS缓存（可以在命令行下使用 ipconfig /displaydns 查看）。如果找到且没有过期则成功。
• 如果（2）中未找到，那么尝试读取位于C:\Windows\System32\drivers\etc下的hosts文件，如果找到对应的IP地址则解析成功。
• 如果（3）中未找到，浏览器首先会找TCP/IP参数中设置的本地DNS服务器，并请求LDNS服务器来解析这个域名，这台服务器一般在你的城市的某个角落，距离你不会很远，并且这台服务器的性能都很好，一般都会缓存域名解析结果，大约80%的域名解析到这里就完成了。否则本地DNS服务器会请求根DNS服务器。
• 本地DNS会把请求发至13台根DNS，根DNS服务器会返回所查询域的主域名服务器的地址(.net)，本地DNS服务器使用该IP信息联系负责.net域的这台服务器。这台负责.net域的服务器收到请求后，会返回.net域的下一级DNS服务器地址(blog.csdn.net)给本地DNS服务器。以此类推，直至找到。

1.2、 TCP / UDP

1.2.1、 准备知识

1）ACK ，TCP协议规定只有ACK=1时有效，也规定连接建立后所有发送的报文的ACK必须为1。
（2）SYN，在连接建立时用来同步序号。当SYN=1而ACK=0时，表明这是一个连接请求报文。对方若同意建立连接，则应在响应报文中使SYN=1和ACK=1，因此SYN置1就表示这是一个连接请求或连接接受报文。
（3）FIN，用来释放一个连接。当 FIN = 1 时，表明此报文段的发送方的数据已经发送完毕，并要求释放连接。

1.2.2、三次握手

最初两端的TCP进程都处于CLOSED关闭状态，A主动打开连接，而B被动打开连接（由客户端执行connect触发）并开始监听。

（1）第一次握手：由Client发出请求连接数据包： SYN=1 ACK=0 seq=x，TCP规定SYN=1时不能携带数据，但要消耗一个序号，因此声明自己的序号是 seq=x，此时Client进入SYN-SENT（同步已发送）状态，等待Server确认；
（2）第二次握手：Server收到请求报文后，进行回复确认，即 SYN=1 ACK=1 seq=y，ack=x+1，此时Server进入SYN-RCVD（同步收到）状态，操作系统为TCP连接分配TCP缓存和变量；
（3）第三次握手：Client收到Server的确认（SYN+ACK）后，向Server发出确认报文段，即 ACK=1，seq=x+1， ack=y+1，TCP连接已经建立，Client进入ESTABLISHED（已建立连接）状态；

Server收到Client的确认后，也进入ESTABLISHED状态，完成三次握手；此时Client和Server可以开始传输数据。

1.2.3、四次握手

数据传输结束后，通信的双方都可释放连接，A和B都处于ESTABLISHED状态。当Client没有数据再需要发送给服务端时，就需要释放客户端的连接，整个过程为：
（1）第一次挥手：当Client发起终止连接请求的时候，会发送一个（FIN为1,seq=u）的没有数据的报文，这时Client停止发送数据（但仍可以接受数据） ，进入FIN_WAIT1（终止等待1）状态，等待Server确认
（2）第二次挥手：Server收到连接释放报文后会给Client一个确认报文段（ACK=1,ack=u+1,seq=v）， 进入CLOSE-WAIT（关闭等待）状态
Client收到Server的确认后进入FIN_WAIT2状态，等待Server请求释放连接，Server仍可向Client发送数据。
（3）第三次挥手：Server数据发送完成后，向Client发起请求连接释放报文（FIN=1,ACK=1,seq=w,ack = u+1）,Server进入LAST-ACK（最后确认）状态，等待Client确认
（4）第四次挥手：Client收到连接释放报文段后，回复一个确认报文段（ACK=1,seq=u+1,ack=w+1），进入 TIME_WAIT（时间等待） 状态，Server收到后进入CLOSED（连接关闭）状态。经过等待2MSL 时间（最大报文生存时间），Client进入CLOSED状态。

面试问题

1、三次握手中为什么Client最后还要发送一次确认呢？可以二次握手吗？=TCP三次握手的主要目的

为了实现可靠数据传输， TCP 协议的通信双方， 都必须维护一个序列号， 以标识发送出去的数据包中， 哪些是已经被对方收到的。 三次握手的过程即是通信双方相互告知序列号起始值， 并确认对方已经收到了序列号起始值的必经步骤
如果只是两次握手， 至多只有连接发起方的起始序列号能被确认， 另一方选择的序列号则得不到确认

2、为什么需要握手？

TCP 协议为了实现可靠传输， 通信双方需要判断自己已经发送的数据包是否都被接收方收到， 如果没收到， 就需要重发。 为了实现这个需求， 很自然地就会引出序号（sequence number） 和 确认号（acknowledgement number） 的使用。
发送方在发送数据包（假设大小为 10 byte）时， 同时送上一个序号( 假设为 500)，那么接收方收到这个数据包以后， 就可以回复一个确认号（510 = 500 + 10） 告诉发送方 “我已经收到了你的数据包， 你可以发送下一个数据包， 序号从 510 开始” 。
这样发送方就可以知道哪些数据被接收到，哪些数据没被接收到， 需要重发。

3、为什么需要三次握手？

为了实现可靠传输，发送方和接收方始终需要同步( SYNchronize )序号。 需要注意的是， 序号并不是从 0 开始的， 而是由发送方随机选择的初始序列号 ( Initial Sequence Number, ISN )开始 。 由于 TCP 是一个双向通信协议， 通信双方都有能力发送信息， 并接收响应。 因此， 通信双方都需要随机产生一个初始的序列号， 并且把这个起始值告诉对方

4、三次握手的理解

第一次握手： A给B打电话说，你可以听到我说话吗？
第二次握手： B收到了A的信息，然后对A说： 我可以听得到你说话啊，你能听得到我说话吗？
第三次握手： A收到了B的信息，然后说可以的，我要给你发信息啦！
在三次握手之后，A和B都能确定这么一件事： 我说的话，你能听到； 你说的话，我也能听到。 这样，就可以开始正常通信了。
如果两次，那么B无法确定B的信息A是否能收到，所以如果B先说话，可能后面的A都收不到，会出现问题 。
如果四次，那么就造成了浪费，因为在三次结束之后，就已经可以保证A可以给B发信息，A可以收到B的信息； B可以给A发信息，B可以收到A的信息。

5、四次挥手的理解

A:“喂，我不说了 (FIN)。”A->FIN_WAIT1
B:“我知道了(ACK)。等下，上一句还没说完。Balabala……（传输数据）”B->CLOSE_WAIT | A->FIN_WAIT2
B:”好了，说完了，我也不说了（FIN）。”B->LAST_ACK
A:”我知道了（ACK）。”A->TIME_WAIT | B->CLOSED
A等待2MSL,保证B收到了消息,否则重说一次”我知道了”,A->CLOSED
这样，通过四次挥手，可以把该说的话都说完，并且A和B都知道自己没话说了，对方也没花说了，然后就挂掉电话（断开链接）了 。

6、Server端易受到SYN攻击？什么是SYN攻击？

SYN洪泛攻击：
服务器端的资源分配是在二次握手时分配的，而客户端的资源是在完成三次握手时分配的，所以服务器容易受到SYN洪泛攻击，SYN攻击就是Client在短时间内伪造大量不存在的IP地址，并向Server不断地发送SYN包，Server则回复确认包，并等待Client确认，由于源地址不存在，因此Server需要不断重发直至超时，这些伪造的SYN包将长时间占用未连接队列，导致正常的SYN请求因为队列满而被丢弃，从而引起网络拥塞甚至系统瘫痪。
防范SYN攻击措施：降低主机的等待时间使主机尽快的释放半连接的占用，短时间受到某IP的重复SYN则丢弃后续请求。
SYN Cookie 防御
，与前面接收到SYN 报文就分配缓存不同，此时暂不分配资源；同时利用SYN 报文的源和目的地IP和端口，以及服务器存储的一个秘密数，使用它们进行散列，得到server_isn，然后附着在SYNACK 报文中发送给客户端，接下来就是对ACK 报文进行判断，如果其返回的ack字段正好等于server_isn + 1，说明这是一个合法的ACK，那么服务器才会为其生成一个具有套接字的全开的连接。

7、为什么A在TIME-WAIT状态必须等待2MSL的时间？

MSL最长报文段寿命Maximum Segment Lifetime，MSL=2
（1）保证A发送的最后一个ACK报文段能够到达B。
这个ACK报文段有可能丢失，使得处于LAST-ACK状态的B收不到对已发送的FIN+ACK报文段的确认，B超时重传FIN+ACK报文段，而A能在2MSL时间内收到这个重传的FIN+ACK报文段，接着A重传一次确认，重新启动2MSL计时器，最后A和B都进入到CLOSED状态，若A在TIME-WAIT状态不等待一段时间，而是发送完ACK报文段后立即释放连接，则无法收到B重传的FIN+ACK报文段，所以不会再发送一次确认报文段，则B无法正常进入到CLOSED状态。
（2）防止“防止本次已失效的连接请求报文段出现在新的连接中
A在发送完最后一个ACK报文段后，再经过2MSL，就可以使本连接持续的时间内所产生的所有报文段都从网络中消失，使下一个新的连接中不会出现这种旧的连接请求报文段。

8、为什么连接的时候是三次握手，关闭的时候却是四次握手？

当Server端收到Client端的SYN连接请求报文后，可以直接发送SYN+ACK报文。其中ACK报文是用来应答的，SYN报文是用来同步的。但是关闭连接时，当Server端收到FIN报文时，很可能并不会立即关闭SOCKET（服务端数据未传输完毕），FIN报文仅仅表示Client没有需要发送的数据，但是仍能接受数据，Server的数据未必全部发送出去，需要等待Server的数据发送完毕后发送FIN报文给Client才能表示同意关闭连接。
所以只能先回复一个ACK报文，告诉Client端，“你发的FIN报文我收到了”。只有等到我Server端所有的报文都发送完了，我才能发送FIN报文，因此不能一起发送。故需要四步握手。

9、如果已经建立了连接，但是客户端突然出现故障了怎么办？

TCP还设有一个保活计时器，显然，客户端如果出现故障，服务器不能一直等下去，白白浪费资源。服务器每收到一次客户端的请求后都会重新复位这个计时器，时间通常是设置为2小时，若两小时还没有收到客户端的任何数据，服务器就会发送一个探测报文段，以后每隔75秒钟发送一次。若一连发送10个探测报文仍然没反应，服务器就认为客户端出了故障，接着就关闭连接。

10、TCP与UDP的区别

UDP 和 TCP 协议都是基于同样的互联网基础设施， 且都基于 IP 协议实现

1.3、网络协议

网络协议是网络上所有设备（网络服务器、计算机及交换机、路由器、防火墙等）之间通信规则的集合，它规定了进行网络中的对等实体数据交换而建立的规则。由于大多数网络采用分层的体系结构，网络各层发送方与接收方（对等实体）应该用相同的网络协议才能相互交换信息。
Internet上的计算机采用TCP/IP协议。

1.4 TCP/IP协议

1.4.1、TCP/IP四层模型与OSI七层模型

OSI七层模型ISO（国际标准化组织）提出的一套理论性的网络标准化协议，它在指定之前是没有经过实践的，我们在实践的过程中发现有些功能不必要分得那么细，TCP四层模型就是我们实践过程中发现比较合理的分层，OSI对我们实践过程分层有着指导性的意义。

TCP/IP四层模型
（1）网络接口层（数据链路层）
作用：实现互连在同一种数据链路（传输介质）结点之间帧传递
功能：组帧、差错控制、流量控制和传输管理

（2）网络层（网际层）
作用：解决数据由一个计算机的IP如何路由到目标计算机的过程规范，我们的计算机消息发送出去后，是经过了哪些处理才能正确的找到目标计算机，其中包含了IP、ARP、RARP、ICMP等协议。
功能：1、封装数据成分组、包，路由选择2、流量控制、拥塞控制&网际互联
ARP协议：实现IP地址向物理地址的映射\ RARP协议：实现物理地址向IP地址的映射
ICMP协议：探测&报告传输中产生的错误\IGMP协议：管理多播组测成员关系

（3）传输层
作用：主要为两台主机上的应用提供端到端的通信，为应用层（会话）提供可靠无误的数据传输服务，为网络层提供源端与目的端的端口信息。
协议： TCP和UDP
端口号：用来识别同一台计算机中进行通信的不同应用程序（传输层协议）
IP地址：用来识别TCP/IP网络中互连的主机和路由器（网际层协议）
MAC地址：用来识别同一链路中不同计算机（网络接口层协议）

（4）应用层
作用：负责处理特定的应用进程（主机运行的程序）间通信&交互规则
2）协议：HTTP协议：提供Internet网浏览服务\DNS协议：负责域名和IP地址的映射\SMTP协议：提供简单电子右键发送服务\POP、IMAP协议：提供邮箱服务器进行远程存取邮件\FTP协议：提供应用级文件传输服务\Telent协议：提供远程登录服务（明文）\ssh协议：提供远程登录服务（加密）

1.4.2、TCP/IP协议族

实现TPC/IP协议功能包括数据的发送、与硬件的交互、消息路由规则、格式定义、错误验证，每个功能有对应的协议规范，所以我们把这些协议统称为TCP/IP协议族。

1.5 Http协议

1.5.1、Http协议定义

• HTTP协议（HyperText Transfer Protocol，超文本传输协议）是用于从WWW服务器传输超文本到本地浏览器的传输协议。
• 基于TCP/IP通信协议传递数据（HTML、图片文件，查询结果等）
• HTTP允许传输任意类型的数据对象，正在传输的类型由Content-Type加以标记
• HTTP是一个无连接的协议：无连接的含义是限制每次连接只处理一个请求。服务器处理完客户的请求，并收到客户的应答后，即断开连接。采用这种方式可以节省传输时间。
• HTTP是一个无状态的协议：无状态是指协议对于事务处理没有记忆能力。缺少状态意味着如果后续处理需要前面的信息，则它必须重传

1.5.2、Http工作流程

（1）客户端通过网络与Web服务端的HTTP端口（默认80）建立TCP连接（TCP协议）
（2）客户端向服务器发送HTTP请求命令，如：GET/sample/hello.jsp HTTP/1.1
（3）客户端发送请求头信息，之后发送一空白行通知服务器已结束该头信息发送
（4）服务器对客户端的请求进行应答，如：HTTP/1.1 200 OK
（5）服务器返回响应头信息，之后发送一空白行通知客户端已结束该头信息发送
（6）服务器向客户端发送数据，以 Content-Type 响应头信息所描述的格式发送用户所请求的实际数据
（7）服务器关闭TCP连接
如果客户端或者服务器在其头信息加入了这行代码 Connection:keep-alive ，TCP 连接在发送后将仍然保持打开状态，于是，客户端可以继续通过相同的连接发送请求。保持连接节省了为每个请求建立新连接所需的时间，还节约了网络带宽

1.5.3、URI与URL

（1）URI：uniform resource identifier，统一资源标识符，用来唯一的标识一个资源。Web上可用的每种资源如HTML文档、图像、视频片段、程序等都是一个来URI来定位的。
URI一般由三部组成：①访问资源的命名机制②存放资源的主机名③资源自身的名称，由路径表示，着重强调于资源。
（2）URL：uniform resource locator，统一资源定位器，它是一种具体的URI，即URL可以用来标识一个资源，而且还指明了如何locate这个资源。
采用URL可以用一种统一的格式来描述各种信息资源，包括文件、服务器的地址和目录等。URL一般由三部组成：①协议(或称为服务方式)②存有该资源的主机IP地址(有时也包括端口号)③主机资源的具体地址。如目录和文件名等

1.5.4、Http协议报文结构

请求报文结构

用于 HTTP 协议交互的信息被称为 HTTP 报文。请求端（客户端）的 HTTP 报文叫做请求报文；响应端（服务器端）的叫做响应报文。HTTP 报文本身是由多行（用 CR+LF 作换行符）数据构成的字符串文本。

组成
通常一个HTTP请求报文由请求行、请求报头、空行和请求数据4个部分组成
（1）)请求行

POST http://patientapi.shoujikanbing.com/api/common/getVersion HTTP/1.1       //请求行
Content-Length: 226                                                          //请求报头
Content-Type: application/x-www-form-urlencoded    
Host: patientapi.shoujikanbing.com
Connection: Keep-Alive
User-Agent: Mozilla/5.0 (Linux; U; Android 4.4.4; zh-cn; MI NOTE LTE Build/KTU84P) AppleWebKit/533.1 (KHTML, like Gecko) Version/4.0 Mobile Safari/533.1
Accept-Encoding: gzip
//不能省略的空格，下面是请求数据
clientversion=2_2.0.0&time=1459069342&appId=android&channel=hjwang&sessionId=0d1cee1f31926ffa8894c64804efa855101d56eb21caf5db5dcb9a4955b7fbc9&token=b191944d680145b5ed97f2f4ccf03058&deviceId=869436020220717&type=2&version=2.0.0

• Method 用于请求的方法（请求访问服务器类型）一共八种
• Request-URI 请求URI（请求访问的资源对象）是一个统一资源标识符，如：/index.htm
• HTTP-Version HTTP版本号HTTP/1.1
• CRLF表示回车和换行（除了作为结尾的CRLF外，不允许出现单独的CR或LF字符）
• Get与Post请求区别
  
  （2）请求报头
  在请求行之后会有0个或者多个请求报头，每个请求报头都包含一个名字和一个值，它们之间用“：”分割。
  服务端需要的附加信息（报文主体大小、所使用的语言、认证信息等内容）
• Host：请求的主机名，允许多个域名同处一个IP地址，即虚拟主机
• User-Agent：发送请求的浏览器类型、操作系统等信息
• Accept：客户端可识别的内容类型列表，用于指定客户端接收那些类型的信息
• Accept-Encoding：客户端可识别的数据编码
• Accept-Language：表示浏览器所支持的语言类型
• Connection：允许客户端和服务器指定与请求/响应连接有关的选项，例如这是为Keep-Alive则表示保持连接。
• Transfer-Encoding：告知接收端为了保证报文的可靠传输，对报文采用了什么编码方式

（3）空行
报文首部与报文主体间空行隔开

（4）请求数据

常见请求头：

响应报文结构

组成：状态行、 首部行、实体

HTTP/1.1 200 OK               //状态行
Date: Fri, 22 May 2009 06:07:21 GMT 
Content-Type: text/html; charset=UTF-8  
<html>
<head></head>
       <body>
             <!--body goes here-->
       </body>
    </html>

状态行

• HTTP-Version 服务器HTTP协议版本号HTTP/1.1
• Status-Code 服务器返回的响应状态代码的状态码200
• Reason-Phrase 状态代码的文本描述
  状态码
  状态代码有三位数字组成，第一个数字定义了响应的类别，共分五种类别:
• 1xx：指示信息–表示请求已接收，继续处理
• 2xx：成功–表示请求已被成功接收、理解、接受 200 成功
• 3xx：重定向–要完成请求必须进行更进一步的操作 301 - 资源（网页等）被永久转移到其它URL
• 4xx：客户端错误–请求有语法错误或请求无法实现 404 请求的资源（网页等）不存在 400 ： 语法错误
• 5xx：服务器端错误–服务器未能实现合法的请求 500 - 内部服务器错误
• 具体状态码可看 https://www.runoob.com/http/http-status-codes.html

响应头部
客户端需要的附加信息（报文主体大小、所使用的语言、认证信息等内容），用于客户端传递自身信息的响应。响应报头见下响应头部，常见的响应报头有：

• Location：用于重定向接受者到一个新的位置，常用在更换域名的时候

• Server：包含可服务器用来处理请求的系统信息，与User-Agent请求报头是相对应的

常见响应头

1.5.5、Cookie和Session

均是解决HTTP无状态协议的一种记录客户状态的机制。

Cookie

由W3C组织提出，最早由Netscape社区发展的一种机制.
Cookie实际上是一小段的文本信息。客户端请求服务器，如果服务器需要记录该用户状态，就使用response向客户端浏览器颁发一个Cookie。客户端浏览器会把Cookie保存起来。当浏览器再请求该网站时，浏览器把请求的网址连同该Cookie一同提交给服务器。服务器检查该Cookie，以此来辨认用户状态。服务器还可以根据需要修改Cookie的内容。
  如果我们不设置Cookie过期时间，那么这个Cookie将不存放在硬盘上，当浏览器关闭的时候，Cookie就消失了。如果我们设置这个时间为若干天之后，那么这个Cookie会保存在客户端硬盘中，即使浏览器关闭，这个值仍然存在，下次访问相应网站时，同 样会发送到服务器上。

Session

Session是另一种记录客户状态的机制，不同的是Cookie保存在客户端浏览器中，而Session保存在服务器上。客户端浏览器访问服务器的时候，服务器把客户端信息以某种方式记录在服务器上。Session相当于程序在服务器上建立的一份客户档案，客户来访的时候只需要查询客户档案表就可以了。
（1）客户第一次访问时需要为该客户创建Session
（2）在创建Session的同时，服务器会为Session生成一个唯一的Session Id。
（3）在Session创建完成后，就可以调用Session的相关方法往Session中增加内容。
（4）当客户端再次发送请求的时候，会将这个Session Id带上，服务器接收到这个请求之后就会依据Session Id找到对应的Session来确认客户端的身份。
一般情况下，服务器会在一定时间内（默认30分钟）保存这个 Session，过了时间限制，就会销毁这个Session。在销毁之前，程序员可以将用户的一些数据以Key和Value的形式暂时存放在这个 Session中。当然，也有使用数据库将这个Session序列化后保存起来的，这样的好处是没了时间的限制，坏处是随着时间的增加，这个数据 库会急速膨胀，特别是访问量增加的时候。一般还是采取前一种方式，以减轻服务器压力。

Cookie和Session区别

（1）存放位置不同：cookie存放在客户端，session存放在服务端
（2）存取的方式不同：Cookie中只能保存ASCII字符串，Session中可以保存任意类型的数据，甚至Java Bean乃至任何Java类、对象等。
（3）有效期上的不同： Cookie的过期时间可以被设置很长。Session依赖于名为JSESSIONI的Cookie，其过期时间默认为-1，只要关闭了浏览器窗口，该Session就会过期，因此Session不能完成信息永久有效。如果Session的超时时间过长，服务器累计的Session就会越多，越容易导致内存溢出。
（4）安全性的不同：Cookie存储在客户端，对客户端是可见的，可被客户端窥探、复制、修改。而Session存储在服务器上，不存在敏感信息泄露的风险.

基于Token的身份验证的过程

1.用户通过用户名和密码发送请求。
2.程序验证。
3.程序返回一个签名的token 给客户端。
4.客户端储存token,并且每次用于每次发送请求。
5.服务端验证token并返回数据。
每一次请求都需要token。token应该在HTTP的头部发送从而保证了Http请求无状态。我们同样通过设置服务器属性Access-Control-Allow-Origin: ，让服务器能接受到来自所有域的请求。需要主要的是，在ACAO头部标明(designating)时，不得带有像HTTP认证，客户端SSL证书和cookies的证书。

二、Socket

2.1 定义

套接字，是通信的基石，是应用层 与 TCP/IP 协议族通信的中间软件抽象层，本质为一个封装了 TCP / IP协议族 的编程接口（API）（不是协议，是一个编程调用接口，通过socket才能实现http协议，属于传输层）网络上的两个程序通过Socket实现一个双向的通信连接从而进行数据交换。
Socket其实就是一个门面模式，它把复杂的TCP/IP协议族隐藏在Socket接口后面，对用户来说，一组简单的接口就是全部，让Socket去组织数据，以符合指定的协议

2.2 原理

应用层通过传输层进行数据通信时，TCP会遇到同时为多个应用程序提供并发服务的问题，多个TCP连接多个应用程序进程可能需要通过同一个TCP协议端口传输数据，为了区别不同的应用程序进程和连接，许多计算机操作系统为应用程序与TCP/IP协议交互提供了套接字（socket）接口，应用层可以和传输层通过socket接口区分来自于不同应用进程或网络连接的通信，实现数据传输的并发服务。

即Socket相当于一个封装了TCP/IP协议的API，提供了程序内部与外界通信的端口，并为通信双方提供了数据传输通道。Socket类型为流套接字（streamsocket）和数据报套接字(datagramsocket)。流套接字将TCP作为其端对端协议，提供了一个可信赖的字节流服务。数据报套接字使用UDP协议，提供数据打包发送服务。

2.3 通信模型

2.4 Socket与Http的区别

1）定义
Socket是套接字，对TCP/IP协议的封装。对端（IP地址和端口）的抽象表示。
HTTP协议是通信协议，是利用TCP在Web服务器和浏览器之间数据传输的协议。
Socket和HTTP协议本质上就不同。SOCKET本质对TCP/IP的封装，从而提供给程序员做网络通信的接口（即端口通信）。可理解为HTTP是一辆轿车模型框架，提供了所有封装和数据传递的形式；Socket是发动机，提供了网络通信的能力。
（2）功能
Socket：属于传输层，因为 TCP / IP协议属于传输层，解决的是数据如何在网络中传输的问题。
HTTP协议：属于 应用层，解决的是如何包装数据。
（3）工作方式
Http
采用 请求—响应 方式。
即建立网络连接后，当 客户端 向 服务器 发送请求后，服务器端才能向客户端返回数据。
可理解为：是客户端有需要才进行通信。

Socket
采用 服务器主动发送数据 的方式。
即建立网络连接后，通信双方即可开始发送数据内容，直到双方连接断开。即服务器可主动发送消息给客户端，实现信息的主动推送；而不需要由客户端向服务器发送请求。
可理解为：是服务器端有需要才进行通信。

2.5 实例

客户端：

public class MainActivity extends AppCompatActivity implements View.OnClickListener {

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);
        Button btn_accept = (Button) findViewById(R.id.btn_accept);
        btn_accept.setOnClickListener(this);
    }

    @Override
    public void onClick(View v) {
        new Thread() {
            @Override
            public void run() {
                try {
                    acceptServer();
                } catch (IOException e) {
                    e.printStackTrace();
                }
            }
        }.start();
    }

    private void acceptServer() throws IOException {
        //1.创建客户端Socket，指定服务器地址和端口
        Socket socket = new Socket("172.16.2.54", 12345);
        //2.获取输出流，向服务器端发送信息
        OutputStream os = socket.getOutputStream();//字节输出流
        PrintWriter pw = new PrintWriter(os);//将输出流包装为打印流
        //获取客户端的IP地址
        InetAddress address = InetAddress.getLocalHost();
        String ip = address.getHostAddress();
        pw.write("客户端：~" + ip + "~ 接入服务器！！");
        pw.flush();
        socket.shutdownOutput();//关闭输出流
        socket.close();
    }}
}}

服务端:

ServerSocket ss =new ServerSocket(30000);
while(true){
	Socket s = ss.accept();
	……
} 

public class SocketServer {
    public static void main(String[] args) throws IOException {
        //1.创建一个服务器端Socket，即ServerSocket，指定绑定的端口，并监听此端口
        ServerSocket serverSocket = new ServerSocket(12345);
        InetAddress address = InetAddress.getLocalHost();
        String ip = address.getHostAddress();
        Socket socket = null;
        //2.调用accept()等待客户端连接
        System.out.println("~~~服务端已就绪，等待客户端接入~，服务端ip地址: " + ip);
        socket = serverSocket.accept();
        //3.连接后获取输入流，读取客户端信息
        InputStream is=null;
        InputStreamReader isr=null;
        BufferedReader br=null;
        OutputStream os=null;
        PrintWriter pw=null;
        is = socket.getInputStream();     //获取输入流
        isr = new InputStreamReader(is,"UTF-8");
        br = new BufferedReader(isr);
        String info = null;
        while((info=br.readLine())!=null){
        	//循环读取客户端的信息
            System.out.println("客户端发送过来的信息" + info);
        }
        socket.shutdownInput();//关闭输入流
        socket.close();
    }
}

三、WebSocket

3.1 定义

WebSocket protocol 是HTML5一种新的协议。它借鉴了socket这种思想，为web应用程序客户端和服务端之间（注意是客户端服务端）提供了一种全双工通信机制(full-duplex)。同时，它又是一种新的应用层协议。一开始的握手需要借助HTTP请求完成。

格式：
ws://echo.websocket.org/?encoding=text HTTP/1.1

3.2 原理流程

• 浏览器、服务器建立TCP连接，三次握手。这是通信的基础，传输控制层，若失败后续都不执行。
• TCP连接成功后，浏览器通过HTTP协议向服务器传送WebSocket支持的版本号等信息。（开始前的HTTP握手）
• 服务器收到客户端的握手请求后，同样采用HTTP协议回馈数据。
• 当收到了连接成功的消息后，通过TCP通道进行传输通信。

3.3 websocket与HTTP

相同点

• 都是一样基于TCP的，都是可靠性传输协议。
• 都是应用层协议。

不同点

• 双向通信
  WebSocket是双向通信协议，模拟Socket协议，可以双向发送或接受信息。在建立连接后，WebSocket 服务器和 Browser/Client Agent 都能主动的向对方发送或接收数据。HTTP是单向的。是一种请求-响应协议，需要客户端发出请求，服务端进行响应。
• 三次握手
  WebSocket是需要握手进行建立连接的。WebSocket在建立握手时，数据是通过HTTP传输的。但是建立之后，在真正传输时候是不需要HTTP协议的。
• 持久连接
  相对于传统 HTTP 每次请求-应答都需要客户端与服务端建立连接的模式，WebSocket 是类似 Socket 的 TCP 长连接的通讯模式，一旦 WebSocket 连接建立后，后续数据都以帧序列的形式传输。在客户端断开 WebSocket 连接或 Server 端断掉连接前，不需要客户端和服务端重新发起连接请求。在海量并发及客户端与服务器交互负载流量大的情况下，极大的节省了网络带宽资源的消耗，有明显的性能优势，且客户端发送和接受消息是在同一个持久连接上发起，实时性优势明显。

四、Https协议

4.1 定义

HTTPS（Hyper Text Transfer Protocol over Secure Socket Layer）是以安全为目标的Http通道，可理解为HTTP的加强版。实现原理是再HTTP下加入SSL层，SSL负责加密和解密数据（HTTPS = HTTP + SSL）

4.2 SSL/TLS

TLS与SSL在传输层对网络连接进行加密.

• SSL记录协议（SSL Record Protocol）：它建立在可靠的传输协议（如TCP）之上，为高层协议提供数据封装、压缩、加密等基本功能的支持。 （通过对称加密实现，用来保证数据传输过程中完整性和私密性）
• SSL握手协议（SSL Handshake Protocol）：它建立在SSL记录协议之上，用于在实际的数据传输开始前，通讯双方进行身份认证、协商加密算法、交换加密密钥等。（通过非对称加密实现，负责握手过程的身份认证）

对称加密

原理：加密算法是公开的，靠的是密钥来加密数据。使用一个密钥加密，使用相同的密钥才能解密
常用算法：DES,3DES,AES
优点：计算量小，加密和解密速度较快，适合加密较大数据
缺点：在传输加密数据之前需要传递密钥，密钥传输容易泄露；一个用户需要对应一个密钥，服务器管理密钥比较麻烦

非对称加密

原理：加密算法是公开的，有一个公钥，一个私钥（公钥和私钥不是随机的，由加密算法生成）；公钥加密只能私钥解密，私钥加密只能公钥解密，加密解密需要不同密钥
常用算法：RSA
优点：可以传输公钥（服务器—>客户端）和公钥加密的数据（客户端->服务器），数据传输安全
缺点：计算量大，加密和解密速度慢

SSL证书种类

（1）域名型https证书（DVSSL），信任等级一般，只需网站的真实性便可办法证书保护网站；
（2）企业型https证书（OVSSL），信任等级强，需验证企业身份，审核严格，安全性高；
（3）增强型https证书（EVSSL），信任等级最高，一般用于银行证券等金融机构，审核严格，安全性最高，可激活绿色网址栏

Https加密解密证书验证过程

优缺点

优点

• 使用HTTPS协议可认证用户和服务器，确保数据发送到正确的客户机和服务器
• HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议，要比HTTP协议安全，防止数据在传输过程中被窃取，确保数据的完整性
• HTTPS是现行架构下最安全的解决方案，虽然不是绝对安全，但是它大幅度增加了中间人攻击的成本

缺点

• 相同网络环境下,HTTPS协议会使页面的加载时间延长50%，增加10%~20%耗电，此外,HTTPS协议还会影响缓存，增加数据开销和功耗（增加了加密解密过程）
• HTTPS协议的安全是有范围的，在黑客攻击、拒绝服务攻击、服务器劫持方面几乎起不到什么作用
  最关键的，SSL证书信用链体系并不安全，特别是再某些国家可以控制CA根证书的情况下，中间人攻击一样可行
• 成本方面：
  （1）SSL的专业证书需要购买，功能越强大，费用越高
  （2）SSL证书通常需要绑定固定IP，为服务器增加固定IP会增加一定费用
  （3）HTTPS连接服务器端资源占用高，相同负载下会增加带宽和投入成本