安卓网络基础面试问题大全

TCP/IP

1.网络分层

2.TCP协议首部

3.TCP/IP 的连接过程

TCP:

• TCP 提供一种面向连接的、可靠的字节流服务

• 在一个 TCP 连接中，仅有两方进行彼此通信。广播和多播不能用于 TCP

• TCP 给数据分节进行排序，并使用累积确认保证数据的顺序不变和非重复

• TCP 使用滑动窗口机制来实现流量控制，通过动态改变窗口的大小进行拥塞控制

TCP 并不能保证数据一定会被对方接收到，因为这是不可能的。TCP 能够做到的是，如果有可能，就把数据递送到接收方，否则就（通过放弃重传并且中断连接这一手段）通知用户。因此准确说 TCP 也不是 100% 可靠的协议，它所能提供的是数据的可靠递送或故障的可靠通知。

重要标志位

• ACK： TCP协议规定，只有ACK=1时有效，也规定连接建立后所有发送的报文的ACK必须为1

• SYN(SYNchronization) ： 在连接建立时用来同步序号。当SYN=1而ACK=0时，表明这是一个连接请求报文。对方若同意建立连接，则应在响应报文中使SYN=1和ACK=1. 因此, SYN置1就表示这是一个连接请求或连接接受报文。

• FIN （finis）即完，终结的意思， 用来释放一个连接。当 FIN = 1 时，表明此报文段的发送方的数据已经发送完毕，并要求释放连接。

1.建立连接

所谓的三次握手，是指建立一个TCP连接时，客服端和服务端总共需要发送3个数据包。

三次握手的目的是：连接服务器端口，建立 TCP 连接，并同步通信双方的序列号和确认号，交换 TCP 窗口大小信息。

详细步骤：

• 设备A 发送 syn 包向设备 B 请求建立 TCP连接，并附带自身的缓冲区信息，然后进入 SYN_SEND 状态，表示请求已发送正在等待回复。
• 设备B 收到请求后，记录设备A的信息，并创建自身的接收缓冲区，向设备A 发送 syn +ack 的合成包，同时自身进入到 SYN_RECV 状态，表示已经准备好了，等待设备 A的会回复就可以向A发送数据了
• A 收到回复之后记录 B的信息，发送 ack 信息，自身进入 ESTABLISHED 状态，表示完全准备好了，可以进行发送和接收
• B 收到 A 的 ack 数据包后，进入 ESTABLISHED 状态。

三次握手的目的：

“三次握手”的目的是“为了防止已失效的连接请求报文段突然又传送到了服务端，因而产生错误”。主要目的防止server端一直等待，浪费资源。换句话说，即是为了保证服务端能收接受到客户端的信息并能做出正确的应答而进行前两次(第一次和第二次)握手，为了保证客户端能够接收到服务端的信息并能做出正确的应答而进行后两次(第二次和第三次)握手。

2.断开连接

• 机器 A 发送完数据之后，向机器B请求断开连接，自身进入FIN_WAIT_1状态，表示数据发送完成且已经发送FIN包（FIN标志位为1）;
• 机器 B 收到FIN包之后，回复ack包表示已经收到，但此时机器 B 可能还有数据没发送完成，自身进入CLOSE_WAIT状态，表示对方已发送完成且请求关闭连接，自身发送完成之后可以关闭连接；
• 机器 B 数据发送完成之后，发送FIN包给机器 B ，自身进入LAST_ACK状态，表示等待一个ACK包即可关闭连接；
• 机器 A 收到 FIN包之后，知道机器 B 也发送完成了，回复一个ACK包，并进入TIME_WAIT状态

TIME_WAIT状态比较特殊。当机器A收到机器B的FIN包时，理想状态下，确实是可以直接关闭连接了；但是：

• 我们知道网络是不稳定的，可能机器B 发送了一些数据还没到达（比FIN包慢）；
• 同时回复的ACK包可能丢失了，机器B会重传FIN包；

如果此时机器A马上关闭连接，会导致数据不完整、机器B无法释放连接等问题。所以此时机器A需要等待2个报文生存最大时长，确保网络中没有任何遗留报文了，再关闭连接

• 机器A等待两个报文存活最大时长之后，机器B 接收到ACK报文之后，均关闭连接，进入CLASED状态

“四次挥手”原因是因为tcp是全双工模式，接收到FIN时意味将没有数据再发来，但是还是可以继续发送数据。

3.TCP/UDP区别

面向报文

面向报文的传输方式是应用层交给 UDP 多长的报文，UDP 发送多长的报文，即一次发送一个报文。因此，应用程序必须选择合适大小的报文。若报文太长，则IP层需要分片，降低效率；若太短，会使IP数据报太小。

面向字节流

面向字节流的话，虽然应用程序和 TCP 的交互是一次一个数据块（大小不等），但 TCP 把应用程序看成是一连串的无结构的字节流。TCP 有一个缓冲，当应用程序传送的数据块太长，TCP 就可以把它划分短一些再传送。

5.Http数据传输的过程

4.TCP可靠传输原理实现（滑动窗口）

TCP的滑动窗口主要有两个作用，一是提供TCP的可靠性，二是提供TCP的流控特性。同时滑动窗口机制还体现了TCP面向字节流的设计思路

• 确认和重传：接收方收到报文后就会进行确认，发送方一段时间没有收到确认就会重传。
• 数据校验：数据合理分片与排序，TCP会对数据进行分片，接收方会缓存为按序到达的数据，重新排序后再提交给应用层。
• 流程控制：当接收方来不及接收发送的数据时，则会提示发送方降低发送的速度，防止包丢失。
• 拥塞控制：当网络发生拥塞时，减少数据的发送。

5.UDP可以进行广播为什么TCP不行?

• UDP 不止支持一对一的传输方式，同样支持一对多，多对多，多对一的方式，也就是说 UDP 提供了单播，多播，广播的功能。
• TCP是一对一，全双工的传输方式

6.如何设计在 UDP 上层保证 UDP 的可靠性传输？

传输层无法保证数据的可靠传输，只能通过应用层来实现了。实现的方式可以参照tcp可靠性传输的方式。如不考虑拥塞处理，可靠UDP的简单设计如下：

• 添加seq/ack机制，确保数据发送到对端
• 添加发送和接收缓冲区，主要是用户超时重传。
• 添加超时重传机制。

具体过程即是：
送端发送数据时，生成一个随机seq=x，然后每一片按照数据大小分配seq。数据到达接收端后接收端放入缓存，并发送一个ack=x的包，表示对方已经收到了数据。发送端收到了ack包后，删除缓冲区对应的数据。时间到后，定时任务检查是否需要重传数据。

目前有如下开源程序利用udp实现了可靠的数据传输。分别为RUDP、RTP、UDT:

• RUDP（Reliable User Datagram Protocol）RUDP 提供一组数据服务质量增强机制，如拥塞控制的改进、重发机制及淡化服务器算法等。

• RTP（Real Time Protocol）RTP为数据提供了具有实时特征的端对端传送服务，如在组播或单播网络服务下的交互式视频音频或模拟数据。

• UDT（UDP-based Data Transfer Protocol）UDT的主要目的是支持高速广域网上的海量数据传输。

---

HTTP 基础

1.Http的报文格式

• 请求报文
  
• 响应报文
  

2.HTTP 各版本特性

1.HTTP 1.0

无状态：服务器不跟踪不记录请求的过程，可以借助 cookie/session 机制来做身份认证和状态记录

无连接：每次请求都需要建立 TCP 连接，TCP通道无法复用，宽带利用率低，http1.0规定在前一个请求响应到达之后下一个请求才能发送，如果前一个阻塞，后面的请求也给阻塞

2.HTTP 1.1

• HTTP 1.1 优化

  • 长连接：引入 Connection: keep-alive 头支持 TCP 连接复用，在一定程度上提高了 TCP的响应速度。
  • 缓存控制：引入 Entiy tag，if-Unmodified-Since，If-Match，cache-control，提供更多的缓存数据控制策略。
  • 带宽优化：引入 range 头域，它允许只请求资源的一部分，文件断电续传基础。
  • 管道化：管道化可以不等第一个请求响应继续发送后面的请求，但响应的顺序还是按照请求的顺序返回。

• HTTP 1.1 存在的问题

  • 数据传输每次都需要重新建立连接
  • 所有的传输都是明文，无法验证对方的身份，无法保证数据的安全性
  • header 里携带的内容过大，在一定程度上增加了传输的成本

3.HTTP 2.0

• 二进制分帧：采用二进制格式的编码
• TCP 通道的多路复用
  • 基于二进制分帧，在同一域名下所有访问都是从同一个tcp连接中走，http 消息被分解为独立的帧，乱序发送，服务端根据标识符和首部将消息重新组装起来
• 支持明文传输，而 SPDY 强制使用 SSL/TLS
• 采用 HPACK 专有算法压缩消息头
• 服务器可以额外的向客户端推送（server push）资源，而无需客户端明确的请求
  

缺点：
多个 HTTP 请求在复⽤⼀个 TCP 连接，下层的 TCP 协议是不知道有多少个 HTTP 请求的。所以⼀旦发⽣了丢包现象，就会触发 TCP 的重传机制，这样在⼀个 TCP 连接中的所有 的 HTTP 请求都必须等待这个丢了的包被重传回来。

4.HTTP 3.0

• 减少了 TCP 三次握手及 TLS 握手时间
• 优化重传策略
• 流量控制
• 传输层采用 UDP
  

5.SPDY

• 多路复用 TCP 通道，降低 HTTP 的高延迟
• 允许请求设置优先级
• header 数据压缩
• 基于 SSL 的安全传输
  

3.HTTP 常见状态码

分类	分类描述
1**	信息，服务器收到请求，需要请求者继续执行操作
2**	成功，操作被成功接收并处理
3**	重定向，需要进一步的操作以完成请求
4**	客户端错误，请求包含语法错误或无法完成请求
5**	服务器错误，服务器在处理请求的过程中发生了错误

4.HTTP的常见请求方式

• GET： 用于获取资源，对服务器的数据不进行修改，不发送 body 数据，GET 把参数包含在 URL 中
• POST：用于增加或修改资源，发送给服务器的数据写在 body 中。
• PUT：用于修改资源，发送给服务器的数据写在 body 中。
• DELETE： 用于删除数据，不发送 body 数据
• HEAD： 与 GET 使用相同，区别在于返回的响应中没有 Body。

不同请求方式的区别:

url 描述了一个网络上资源，而 POST、GET、PUT、DELETE 就是对这个资源进行增、删、改、查的操作！

安全和幂等的概念：

• 在 HTTP 协议⾥，所谓的「安全」是指请求⽅法不会「破坏」服务器上的资源
• 所谓的「幂等」，意思是多次执⾏相同的操作，结果都是「相同」的。

GET ⽅法就是安全且幂等的，因为它是「只读」操作，⽆论操作多少次，服务器上的数据都是安全的，且每次的结果都是相同的。

POST 因为是「新增或提交数据」的操作，会修改服务器上的资源，所以是不安全的，且多次提交数据就会创建多个资源，所以不是幂等的。

PUT，DELETE操作是幂等的。

5.POST 和 GET 的区别

• GET 在浏览器回退时候是无害的，而 POST 会再次提交请求。

• GET 产生的URL地址可以被Bookmark，而 POST 不可以。

• GET 请求会被浏览器主动 cache，而 POST 不会，除非手动设置。

• GET请求只能进行url编码，而POST支持多种编码方式。

• GET请求参数会被完整保留在浏览器历史记录里，而POST中的参数不会被保留。

• GET请求在URL中传送的参数是有长度限制的，而 POST 没有。

• 对参数的数据类型，GET 只接受ASCII字符，而POST没有限制。

• GET 比 POST 更不安全，因为参数直接暴露在URL上，所以不能用来传递敏感信息。

• GET参数通过URL传递，POST放在Request body中。

特别注意：

• GET方式的请求，浏览器会把http header 和data一并发送出去，服务器响应200（返回数据）；

• 而对于POST，浏览器先发送header，服务器响应100 continue，浏览器再发送data，服务器响应200 ok（返回数据）。

• GET产生一个TCP数据包；POST产生两个TCP数据包。

6.Cookie和Session的区别

什么是 Cookie

HTTP Cookie（也叫 Web Cookie或浏览器 Cookie）是服务器发送到用户浏览器并保存在本地的一小块数据，它会在浏览器下次向同一服务器再发起请求时被携带并发送到服务器上。通常，它用于告知服务端两个请求是否来自同一浏览器，如保持用户的登录状态。Cookie 使基于无状态的 HTTP 协议记录稳定的状态信息成为了可能。

主要作用：

• 会话状态管理（如用户登录状态、购物车、游戏分数或其它需要记录的信息）
• 个性化设置（如用户自定义设置、主题等）
• 浏览器行为跟踪（如跟踪分析用户行为等）

什么是 Session

Session 代表着服务器和客户端一次会话的过程。Session 对象存储特定用户会话所需的属性及配置信息。这样，当用户在应用程序的 Web 页之间跳转时，存储在 Session 对象中的变量将不会丢失，而是在整个用户会话中一直存在下去。当客户端关闭会话，或者 Session 超时失效时会话结束。

Cookie 和 Session的区别：

• 作用范围不同，Cookie 保存在客户端（浏览器），Session 保存在服务器端。
• 存取方式的不同，Cookie 只能保存 ASCII，Session 可以存任意数据类型，一般情况下我们可以在 Session 中保持一些常用变量信息，比如说 UserId 等。
• 有效期不同，Cookie 可设置为长时间保持，比如我们经常使用的默认登录功能，Session 一般失效时间较短，客户端关闭或者 Session 超时都会失效。
• 隐私策略不同，Cookie 存储在客户端，比较容易遭到不法获取；Session 存储在服务端，安全性相对 Cookie 要好一些。
• 存储大小不同， 单个 Cookie 保存的数据不能超过 4K，Session 可存储数据远高于 Cookie。

为什么要使用 Cookie 和 Session？

HTTP协议是无状态的，需要依靠 Cookie 和 Session这套机制来告诉服务端当前连接的设备是谁。

7.浏览器输入url地址到反馈结果的过程？

1. DNS解析
2. TCP连接
3. 发送HTTP请求
4. 服务器处理请求并返回HTTP报文
5. 浏览器解析渲染页面
6. 连接结束

8.Http缓存机制

8.1、缓存流程

HTTP的缓存机制也是依赖于请求和响应header里的参数类实现的，最终响应式从缓存中去，还是从服务端重新拉取，HTTP的缓存机制的流程如下所示：

8.2、缓存策略：

• 强制缓存：需要服务端参与判断是否继续使用缓存，当客户端第一次请求数据是，服务端返回了缓存的过期时间（Expires 与Cache-Control），没有过期就可以继续使用缓存，否则则不适用，无需再向服务端询问。
• 对比缓存：需要服务端参与判断是否继续使用缓存，当客户端第一次请求数据时，服务端会将缓存标识（Last-Modified/If-Modified-Since与Etag/If-None-Match）与数据一起返回给客户端，客户端将两者都备份到缓存中 ，再次请求数据时，客户端将上次备份的缓存 标识发送给服务端，服务端根据缓存标识进行判断，如果返回304，则表示通知客户端可以继续使用缓存。
• 强制缓存优先于对比缓存

强制缓存:

Expires：

• Expires的值为服务端返回的到期时间，即下一次请求时，请求时间小于服务端返回的到期时间，直接使用缓存数据。到期时间是服务端生成的，客户端和服务端的时间可能有误差。

Cache-Control：

• Expires: 有个时间校验的问题，所有HTTP1.1采用Cache-Control替代Expires
• private: 客户端可以缓存。
• public: 客户端和代理服务器都可缓存。
• max-age=xxx: 缓存的内容将在 xxx 秒后失效
• no-cache: 需要使用对比缓存来验证缓存数据。
• no-store: 所有内容都不会缓存，强制缓存，对比缓存都不会触发。

对比缓存：

• Last-Modified/If-Modified-Since
  • Last-Modified 表示资源上次修改的时间，当客户端发送第一次请求时，服务端返回资源上次修改的时间
  • 客户端再次发送，会在header里携带If-Modified-Since。将上次服务端返回的资源时间上传给服务端。
  • 服务端接收到客户端发来的资源修改时间，与自己当前的资源修改时间进行对比，如果自己的资源修改时间大于客户端发来的资源修改时间，则说明资源做过修改， 则返回200表示需要重新请求资源，否则返回304表示资源没有被修改，可以继续使用缓存。
• Etag/If-None-Match
  • ETag是资源文件的一种标识码，当客户端发送第一次请求时，服务端会返回当前资源的标识码.
  • 客户端再次发送，会在header里携带上次服务端返回的资源标识码
  • 服务端接收到客户端发来的资源标识码，则会与自己当前的资源吗进行比较，如果不同，则说明资源已经被修改，则返回200，如果相同则说明资源没有被修改，返回 304，客户端可以继续使用缓存。

9.Http长连接？

详细解释“Keep-Alive”有什么用

Http1.0是短连接，HTTP1.1默认是长连接，也就是默认Connection的值就是keep-alive。但是长连接实质是指的TCP连接，而不是HTTP连接。TCP连接是一个双向的通道，它是可以保持一段时间不关闭的，因此TCP连接才有真正的长连接和短连接这一说。

Http1.1为什么要用使用tcp长连接？

长连接是指的TCP连接，也就是说复用的是TCP连接。即长连接情况下，多个HTTP请求可以复用同一个TCP连接，这就节省了很多TCP连接建立和断开的消耗。此外，长连接并不是永久连接的。如果一段时间内（具体的时间长短，是可以在header当中进行设置的，也就是所谓的超时时间），这个连接没有HTTP请求发出的话，那么这个长连接就会被断掉。

10.Http 请求慢的解决办法

原因：带宽和延迟

1.不通过DNS解析，直接访问IP

2.解决连接无法复用

http/1.0协议头里可以设置Connection:Keep-Alive或者Connection:Close，选择是否允许在一定时间内复用连接（时间可由服务器控制）。但是这对App端的请求成效不大，因为App端的请求比较分散且时间跨度相对较大。

方案1.基于tcp的长连接

移动端建立一条自己的长链接通道，通道的实现是基于tcp协议。基于tcp的socket编程技术难度相对复杂很多，而且需要自己定制协议。但信息的上报和推送变得更及时，请求量爆发的时间点还能减轻服务器压力（避免频繁创建和销毁连接）

方案2.http long-polling

客户端在初始状态发送一个polling请求到服务器，服务器并不会马上返回业务数据，而是等待有新的业务数据产生的时候再返回，所以链接会一直被保持。一但结束当前连接，马上又会发送一个新的polling请求，如此反复，保证一个连接被保持。
存在问题：
1）增加了服务器的压力
2）网络环境复杂场景下，需要考虑怎么重建健康的连接通道
3）polling的方式稳定性不好
4）polling的response可能被中间代理cache住
……

方案3.http streaming

和long-polling不同的是，streaming方式通过再server response的头部增加“Transfer Encoding:chuncked”来告诉客户端后续还有新的数据到来
存在问题：
1）有些代理服务器会等待服务器的response结束之后才将结果推送给请求客户端。streaming不会结束response
2）业务数据无法按照请求分割
……

方案4.web socket

和传统的tcp socket相似，基于tcp协议，提供双向的数据通道。它的优势是提供了message的概念，比基于字节流的tcp socket使用更简单。技术较新，不是所有浏览器都提供了支持。

---

HTTPS

1.什么是Https？

HTTPS是一种通过计算机网络进行安全通信的传输协议。HTTPS经由HTTP进行通信，但利用SSL/TLS来加密数据包。HTTPS开发的主要目的，是提供对网站服务器的身份 认证，保护交换数据的隐私与完整性。

HTTPS网络模型

SSL (Secure Socket Layer 安全套接层)是基于HTTPS下的一个协议加密层。

2.HTTPS加密原理

2.1、 加密过程

2.2、客户端如何校验 CA 证书？

CA 证书中的 Hash 值，其实是用证书的私钥进行加密后的值（证书的私钥不在 CA 证书中）。然后客户端得到证书后，利用证书中的公钥去解密该 Hash 值，得到 Hash-a ；然后再利用证书内的签名 Hash 算法去生成一个 Hash-b 。最后比较 Hash-a 和 Hash-b 这两个的值。如果相等，那么证明了该证书是对的，服务端是可以被信任的；如果不相等，那么就说明该证书是错误的，可能被篡改了，浏览器会给出相关提示，无法建立起 HTTPS 连接。除此之外，还会校验 CA 证书的有效时间和域名匹配等。

2.3、HTTPS 中的 SSL 握手建立过程

假设现在有客户端 A 和服务器 B ：

• 1、首先，客户端 A 访问服务器 B ，比如我们用浏览器打开一个网页 www.baidu.com ，这时，浏览器就是客户端 A ，百度的服务器就是服务器 B 了。这时候客户端 A 会生成一个随机数1，把随机数1 、自己支持的 SSL 版本号以及加密算法等这些信息告诉服务器 B 。
• 2、服务器 B 知道这些信息后，然后确认一下双方的加密算法，然后服务端也生成一个随机数 B ，并将随机数 B 和 CA 颁发给自己的证书一同返回给客户端 A 。
• 3、客户端 A 得到 CA 证书后，会去校验该 CA 证书的有效性，校验方法在上面已经说过了。校验通过后，客户端生成一个随机数3 ，然后用证书中的公钥加密随机数3 并传输给服务端 B 。
• 4、服务端 B 得到加密后的随机数3，然后利用私钥进行解密，得到真正的随机数3。
• 5、最后，客户端 A 和服务端 B 都有随机数1、随机数2、随机数3，然后双方利用这三个随机数生成一个对话密钥。之后传输内容就是利用对话密钥来进行加解密了。这时就是利用了对称加密，一般用的都是 AES 算法。
• 6、客户端 A 通知服务端 B ，指明后面的通讯用对话密钥来完成，同时通知服务器 B 客户端 A 的握手过程结束。
• 7、服务端 B 通知客户端 A，指明后面的通讯用对话密钥来完成，同时通知客户端 A 服务器 B 的握手过程结束。
• 8、SSL 的握手部分结束，SSL 安全通道的数据通讯开始，客户端 A 和服务器 B 开始使用相同的对话密钥进行数据通讯。

简化如下：

• 1、客户端和服务端建立 SSL 握手，客户端通过 CA 证书来确认服务端的身份；
• 2、互相传递三个随机数，之后通过这随机数来生成一个密钥；
• 3、互相确认密钥，然后握手结束；
• 4、数据通讯开始，都使用同一个对话密钥来加解密；

可以发现，在 HTTPS 加密原理的过程中把对称加密和非对称加密都利用了起来。即利用了非对称加密安全性高的特点，又利用了对称加密速度快，效率高的好处。

2.4、 Android 与服务器交互的方式中的对称加密和非对称加密是什么?？

采用对称加密+非对称加密

• 对称加密，加密用的密钥和解密用的密钥是同一个，比较有代表性的就是 AES 加密算法；效率高
• 非对称加密，加密用的密钥称为公钥，解密用的密钥称为私钥，经常使用到的 RSA 加密算法就是非对称加密的；效率低。

HTTPS是使用非对称加密的方式将对称加密的密钥传送过去，也就是把密码本锁上给了对方。然后对方得到密文用它自己的钥匙打开锁得到密码本之后，随后就可以用对称加密的方式通信了。

2.5、什么是中间人攻击，HTTPS 如何防范中间人攻击？

HTTPS 如何防范中间人攻击？

当数据传输发生在一个设备（PC/手机）和网络服务器之间时，攻击者使用其技能和工具将自己置于两个端点之间并截获数据；尽管交谈的两方认为他们是在与对方交谈，但是实际上他们是在与干坏事的人交流，这便是中间人攻击。

有几种攻击方式？

• 1、嗅探：
  嗅探或数据包嗅探是一种用于捕获流进和流出系统/网络的数据包的技术。网络中的数据包嗅探就好像电话中的监听。

• 2、数据包注入：
  在这种技术中，攻击者会将恶意数据包注入常规数据中。这样用户便不会注意到文件/恶意软件，因为它们是合法通讯流的一部分。

• 3、会话劫持：
  在你登录进你的银行账户和退出登录这一段期间便称为一个会话。这些会话通常都是黑客的攻击目标，因为它们包含潜在的重要信息。在大多数案例中，黑客会潜伏在会话中，并最终控制它。

• 4、SSL剥离：
  在SSL剥离攻击中，攻击者使SSL/TLS连接剥落，随之协议便从安全的HTTPS变成了不安全的HTTP。

3.HTTPS和HTTP的区别

HTTPS在应用层和传输层之家加了一层安全层：TSL/SSL ，如图所示：

区别如下：

• HTTP 明文传输，数据都是未加密的，安全性较差，HTTPS（SSL+HTTP） 数据传输过程是加密的，安全性较好

• 使用 HTTPS 协议需要申请Ca证书

• HTTP 页面响应速度比 HTTPS 快，主要是因为 HTTP 使用 TCP 三次握手建立连接，客户端和服务器需要交换 3 个包，而 HTTPS除了 TCP 的三个包，还要加上 SSL 握手需要的 9 个包，所以一共是 12 个包。

• HTTP 和 HTTPS 使用的是完全不同的连接方式，用的端口也不一样，前者是 80，后者是 443。

• HTTPS 其实就是建构在 SSL/TLS 之上的 HTTP 协议，所以，要比较 HTTPS 比 HTTP 要更耗费服务器资源

Socket

Socket概念：

套接字（socket）是通信的基石，是支持TCP/IP协议的网络通信的基本操作单元。它是网络通信过程中端点的抽象表示，包含进行网络通信必须的五种信息：

• 连接使用的协议
• 本地主机的IP地址
• 本地进程的协议端口
• 远地主机的IP地址
• 远地进程的协议端口

为了区别不同的应用程序进程和连接，许多计算机操作系统为应用程序与TCP／IP协议交互提供了套接字(Socket)接口。应用层可以和传输层通过Socket接口，区分来自不同应用程序进程或网络连接的通信，实现数据传输的并发服务。

建立socket连接

建立Socket连接至少需要一对套接字，其中一个运行于客户端，称为ClientSocket ，另一个运行于服务器端，称为ServerSocket 。套接字之间的连接过程分为三个步骤：服务器监听，客户端请求，连接确认。

• 服务器监听：服务器端套接字并不定位具体的客户端套接字，而是处于等待连接的状态，实时监控网络状态，等待客户端的连接请求。
• 客户端请求：指客户端的套接字提出连接请求，要连接的目标是服务器端的套接字。为此，客户端的套接字必须首先描述它要连接的服务器的套接字，指出服务器端套接字的 地址 和 端口号，然后就向服务器端套接字提出连接请求。
• 连接确认：当服务器端套接字监听到或者说接收到客户端套接字的连接请求时，就响应客户端套接字的请求，建立一个新的线程，把服务器端套接字的描述发 给客户端，一旦客户端确认了此描述，双方就正式建立连接。而服务器端套接字继续处于监听状态，继续接收其他客户端套接字的连接请求。

SOCKET连接与TCP连接

创建Socket连接时，可以指定使用的传输层协议，Socket可以支持不同的传输层协议（TCP或UDP），当使用TCP协议进行连接时，该Socket连接就是一个TCP连接。

Socket连接与HTTP连接

由于通常情况下Socket连接就是TCP连接，因此Socket连接一旦建立，通信双方即可开始相互发送数据内容，直到双方连接断开。但在实际网 络应用中，客户端到服务器之间的通信往往需要穿越多个中间节点，例如路由器、网关、防火墙等，大部分防火墙默认会关闭长时间处于非活跃状态的连接而导致 Socket 连接断连，因此需要通过轮询告诉网络，该连接处于活跃状态。

而HTTP连接使用的是“请求—响应”的方式，不仅在请求时需要先建立连接，而且需要客户端向服务器发出请求后，服务器端才能回复数据。很多情况下，需要服务器端主动向客户端推送数据，保持客户端与服务器数据的实时与同步。此时若双方建立的是Socket连接，服务器就可以直接将数 据传送给客户端；若双方建立的是HTTP连接，则服务器需要等到客户端发送一次请求后才能将数据传回给客户端，因此，客户端定时向服务器端发送连接请求， 不仅可以保持在线，同时也是在“询问”服务器是否有新的数据，如果有就将数据传给客户端。TCP(Transmission Control Protocol)　传输控制协议

socket断线重连实现

正常连接断开客户端会给服务端发送一个fin包，服务端收到fin包后才会知道连接断开。而断网断电时客户端无法发送fin包给服务端，所以服务端没办法检测到客户端已经短线。
为了缓解这个问题，服务端需要有个心跳逻辑，就是服务端检测到某个客户端多久没发送任何数据过来就认为客户端已经断开，这需要客户端定时向服务端发送心跳数据维持连接。

心跳机制实现

长连接的实现：心跳机制，应用层协议大多都有HeartBeat机制，通常是客户端每隔一小段时间向服务器发送一个数据包，通知服务器自己仍然在线。并传输一些可能必要的数据。使用心跳包的典型协议是IM，比如QQ/MSN/飞信等协议

1、在TCP的机制里面，本身是存在有心跳包的机制的，也就是TCP的选项：SO_KEEPALIVE。系统默认是设置的2小时的心跳频率。但是它检查不到机器断电、网线拔出、防火墙这些断线。
而且逻辑层处理断线可能也不是那么好处理。一般，如果只是用于保活还是可以的。通过使用TCP的KeepAlive机制（修改那个time参数），可以让连接每隔一小段时间就产生一些ack包，以降低被踢掉的风险，当然，这样的代价是额外的网络和CPU负担。

2、应用层心跳机制实现。

参考学习博客：

• 面试官的这份HTTP灵魂追问你Hold住吗？
• 谈谈 HTTPS
• 这一篇TCP总结请收下
• http的长连接和短连接
• 浅谈常见的七种加密算法及实现
• HTTPS加密原理