1.1 請簡述 Http 與 Https 的區(qū)別？

HTTP協(xié)議傳輸?shù)臄?shù)據(jù)都是未加密的，也就是明文的，因此使用HTTP協(xié)議傳輸隱私信息非常不安全，為了保證這些隱私數(shù)據(jù)能加密傳輸，于是網(wǎng)景公司設(shè)計(jì)了SSL（Secure Sockets Layer）協(xié)議用于對HTTP協(xié)議傳輸?shù)臄?shù)據(jù)進(jìn)行加密，從而就誕生了HTTPS。

1、https協(xié)議需要到ca申請證書，一般免費(fèi)證書較少，因而需要一定費(fèi)用。
2、http是超文本傳輸協(xié)議，信息是明文傳輸，https則是具有安全性的ssl加密傳輸協(xié)議。
3、http和https使用的是完全不同的連接方式，用的端口也不一樣，前者是80，后者是443。
4、http的連接很簡單，是無狀態(tài)的；HTTPS協(xié)議是由SSL+HTTP協(xié)議構(gòu)建的可進(jìn)行加密傳輸、身份認(rèn)證的網(wǎng)絡(luò)協(xié)議，比http協(xié)議安全。

最后一點(diǎn)在Android 9.0 如果用http進(jìn)行傳輸，需要在application節(jié)點(diǎn)下設(shè)置

android:usesCleartextTraffic="true"

1.2 說一說https、udp、socket區(qū)別？

https協(xié)議需要到CA申請證書。

http是超文本傳輸協(xié)議，信息是明文傳輸；https 則是具有安全性的ssl加密傳輸協(xié)議。

http和https使用的是完全不同的連接方式，用的端口也不一樣，前者是80，后者是443。

http的連接很簡單，是無狀態(tài)的；HTTPS協(xié)議是由SSL+HTTP協(xié)議構(gòu)建的可進(jìn)行加密傳輸、身份認(rèn)證的網(wǎng)絡(luò)協(xié)議，比http協(xié)議安全。

http默認(rèn)使用80端口，https默認(rèn)使用443端口
TCP：傳送控制協(xié)議(Transmission Control Protocol)
UDP：用戶數(shù)據(jù)報(bào)協(xié)議 （UDP：User DatagramProtocol）
Socket:
這是為了實(shí)現(xiàn)以上的通信過程而建立成來通信管道，其真實(shí)的代表是客戶端和服務(wù)器端的一個(gè)通信進(jìn)程，雙方進(jìn)程通過socket進(jìn)行通信，而通信的規(guī)則采用指定的協(xié)議。
socket只是一種連接模式，不是協(xié)議，socket是對TCP/IP協(xié)議的封裝，Socket本身并不是協(xié)議，而是一個(gè)調(diào)用接口（API），通過Socket，我們才能使用TCP/IP協(xié)議。
tcp、udp，簡單的說（雖然不準(zhǔn)確）是兩個(gè)最基本的協(xié)議，很多其它協(xié)議都是基于這兩個(gè)協(xié)議如，http就是基于tcp的，用socket可以創(chuàng)建tcp連接，也可以創(chuàng)建udp連接，這意味著，用socket可以創(chuàng)建任何協(xié)議的連接，因?yàn)槠渌鼌f(xié)議都是基于此的。

1.3 請簡述一次http網(wǎng)絡(luò)請求的過程？

這個(gè)看OKHTTP的EventListerner就知道了。這里總結(jié)一張okhttp的回調(diào)表格。詳細(xì)的需要自己閱讀源碼注釋。

postman

1.4 談一談TCP/IP三次握手，四次揮手？

常見的 TCP 中的頭部數(shù)據(jù)表示
ACK：該位為 1 時(shí)，「確認(rèn)應(yīng)答」的字段變?yōu)橛行В?br> TCP 規(guī)定除了最初建立連接時(shí)的 SYN 包之外該位必須設(shè)置為 1
SYN：該位為 1 時(shí)，表示希望建立連接，并在其「序列號(hào)」的字段進(jìn)行序列號(hào)初始值的設(shè)定
RST：該位為 1 時(shí)，表示 TCP 連接中出現(xiàn)異常必須強(qiáng)制斷開連接
FIN：該位為 1 時(shí)，表示今后不會(huì)再有數(shù)據(jù)發(fā)送，希望斷開連接。當(dāng)通信結(jié)束希望斷開連接時(shí)，通信雙方的主機(jī)之間就可以相互交換 FIN 位為 1 的 TCP 段

TCP 三次握手

TCP 三次握手

一開始，客戶端和服務(wù)端都處于 CLOSED 狀態(tài)。先是服務(wù)端主動(dòng)監(jiān)聽某個(gè)端口，處于 LISTEN 狀態(tài)

第一個(gè)報(bào)文—— SYN 報(bào)文

客戶端會(huì)隨機(jī)初始化序號(hào)（client_isn），將此序號(hào)置于 TCP 首部的「序號(hào)」字段中，同時(shí)把 SYN 標(biāo)志位置為 1 ，表示 SYN 報(bào)文。接著把第一個(gè) SYN 報(bào)文發(fā)送給服務(wù)端，表示向服務(wù)端發(fā)起連接，該報(bào)文不包含應(yīng)用層數(shù)據(jù)，之后客戶端處于 SYN-SENT 狀態(tài)。

第二個(gè)報(bào)文 —— SYN + ACK 報(bào)文

服務(wù)端收到客戶端的 SYN 報(bào)文后，首先服務(wù)端也隨機(jī)初始化自己的序號(hào)（server_isn），將此序號(hào)填入 TCP 首部的「序號(hào)」字段中，其次把 TCP 首部的 「確認(rèn)應(yīng)答號(hào)」字段填入 client_isn + 1, 接著把SYN 和 ACK 標(biāo)志位置為 1。最后把該報(bào)文發(fā)給客戶端，該報(bào)文也不包含應(yīng)用層數(shù)據(jù)，之后服務(wù)端處于SYN-RCVD 狀態(tài)。

第三個(gè)報(bào)文 —— ACK 報(bào)文

客戶端收到服務(wù)端報(bào)文后，還要向服務(wù)端回應(yīng)最后一個(gè)應(yīng)答報(bào)文，首先該應(yīng)答報(bào)文 TCP 首部 ACK 標(biāo)志位置為 1 ，其次「確認(rèn)應(yīng)答號(hào)」字段填入 server_isn + 1 ，最后把報(bào)文發(fā)送給服端，這次報(bào)文可以攜帶客戶到服務(wù)器的數(shù)據(jù)，之后客戶端處于ESTABLISHED 狀態(tài)。

服務(wù)器收到客戶端的應(yīng)答報(bào)文后，也進(jìn)入 ESTABLISHED 狀態(tài)，此時(shí) TCP 建立結(jié)束，雙方可以收發(fā)數(shù)據(jù)。

為什么是三次握手？不是兩次、四次？

• 三次握手才能保證雙方具有接收和發(fā)送的能力
• 三次握手才可以阻止重復(fù)歷史連接的初始化
• 三次握手才可以同步雙方的初始序列號(hào)
• 三次握手才可以避免資源浪費(fèi)

TCP 四次揮手過程

客戶端主動(dòng)關(guān)閉連接 —— TCP 四次揮手

• 客戶端打算關(guān)閉連接，此時(shí)會(huì)發(fā)送一個(gè) TCP 首部 FIN標(biāo)志位被置為 1 的報(bào)文，也即 FIN 報(bào)文，之后客戶端進(jìn)入 FIN_WAIT_1 狀態(tài)。
• 服務(wù)端收到該報(bào)文后，就向客戶端發(fā)送 ACK 應(yīng)答報(bào)文，接著服務(wù)端進(jìn)入 CLOSED_WAIT 狀態(tài)。
• 客戶端收到服務(wù)端的 ACK 應(yīng)答報(bào)文后，之后進(jìn)入FIN_WAIT_2 狀態(tài)。
• 等待服務(wù)端處理完數(shù)據(jù)后，也向客戶端發(fā)送 FIN 報(bào)文，之后服務(wù)端進(jìn)入 LAST_ACK 狀態(tài)。
• 客戶端收到服務(wù)端的 FIN 報(bào)文后，回一個(gè) ACK 應(yīng)答報(bào)文，之后進(jìn)入 TIME_WAIT 狀態(tài)服務(wù)器收到了 ACK 應(yīng)答報(bào)文后，就進(jìn)入了 CLOSED 狀態(tài)，至此服務(wù)端已經(jīng)完成連接的關(guān)閉。
• 客戶端在經(jīng)過 2MSL 一段時(shí)間后，自動(dòng)進(jìn)入 CLOSED 狀態(tài)，至此客戶端也完成連接的關(guān)閉。

客戶端和服務(wù)端都需要一個(gè) FIN 和一個(gè) ACK，因此通常被稱為四次揮手。

這里一點(diǎn)需要注意是：主動(dòng)關(guān)閉連接的，才有 TIME_WAIT狀態(tài)。

為什么揮手需要四次？

回顧上方四次揮手雙方發(fā) FIN 包的過程，就能理解為什么需要四次了。

• 關(guān)閉連接時(shí)，客戶端向服務(wù)端發(fā)送 FIN 時(shí)，僅僅表示客戶端不再發(fā)送數(shù)據(jù)了但是還能接收數(shù)據(jù)。
• 服務(wù)器收到客戶端的 FIN 報(bào)文時(shí)，先回一個(gè) ACK 應(yīng)答報(bào)文，而服務(wù)端可能還有數(shù)據(jù)需要處理和發(fā)送，等服務(wù)端不再發(fā)送數(shù)據(jù)時(shí)，才發(fā)送 FIN 報(bào)文給客戶端來表示同意現(xiàn)在關(guān)閉連接。

從上面過程可知，服務(wù)端通常需要等待完成數(shù)據(jù)的發(fā)送和處理，所以服務(wù)端的 ACK 和 FIN 一般都會(huì)分開發(fā)送，從而比三次握手導(dǎo)致多了一次。

1.5 為什么說Http是可靠的數(shù)據(jù)傳輸協(xié)議？

HTTP是屬于應(yīng)用層的協(xié)議，TCP（傳輸控制協(xié)議）和UDP（用戶數(shù)據(jù)報(bào)協(xié)議）是屬于傳輸層的協(xié)議。
我們都知道TCP協(xié)議是面向連接的，每次進(jìn)行連接都要進(jìn)行三次握手和四次揮手，所以它的連接是可靠的。而HTTP是在TCP上層的協(xié)議，所以它也是可靠的。

那為什么TCP可靠？
首先來講一下網(wǎng)絡(luò)的分層，因特網(wǎng)協(xié)議可以分為五層，分別是：
應(yīng)用層->傳輸層->網(wǎng)絡(luò)互聯(lián)層->網(wǎng)絡(luò)訪問層->物理層

或許你覺得很抽象，但是通過栗子你就會(huì)發(fā)現(xiàn)并沒有那么復(fù)雜。

如訪問一個(gè)Http請求：http://45.124.252.66:9090/main/
怎么訪問到這個(gè)網(wǎng)站呢？
首先我們需要通過網(wǎng)絡(luò)，可能是移動(dòng)網(wǎng)或者寬帶網(wǎng)等（這就是物理層，它是一個(gè)傳輸介質(zhì)），然后找到對應(yīng)那一臺(tái)被我們訪問的服務(wù)器的mac地址（網(wǎng)絡(luò)訪問層）進(jìn)行連接，再匹配它的IP（網(wǎng)絡(luò)互聯(lián)層）是否對應(yīng)，確定了主機(jī)后，再通過端口號(hào)9090（傳輸層）訪問對應(yīng)的進(jìn)程，由于一個(gè)進(jìn)程里面有很多業(yè)務(wù)模塊，而我們需要訪問main模塊（應(yīng)用層），最終通過不同層來實(shí)現(xiàn)網(wǎng)站的訪問。
每個(gè)層都是相互獨(dú)立，并且向下依賴，而傳輸層是能確定唯一主機(jī)的，因?yàn)槲覀兛梢酝ㄟ^mac地址、host和端口來確定唯一的一臺(tái)訪問主機(jī)上面的進(jìn)程?；蛟S有的人會(huì)問，那如果網(wǎng)絡(luò)中斷呢？那不就不可靠了嗎，我們常說的網(wǎng)絡(luò)中斷是屬于物理層，由于是向下依賴，傳輸層的建立是依賴于下面的三層（網(wǎng)絡(luò)互聯(lián)層、網(wǎng)絡(luò)訪問層、物理層）已經(jīng)連接成功，如果下面的層都沒有連接成功，也就沒有傳輸層這一說了，所以傳輸層協(xié)議是一個(gè)“靠譜”的協(xié)議。

我們通過分層了解了傳輸層是“靠譜”的協(xié)議，那么怎么保證它是可靠的呢？

那就要講到三次握手和四次揮手的作用了。

三次握手就是在建立連接之前需要客戶端先給服務(wù)端發(fā)出SYN(c)報(bào)文，當(dāng)服務(wù)器收到后需要返回客戶端ACK=SYN(c)+1，并且傳輸自己生成的SYN(s)給客戶端，客戶端收到后進(jìn)入已連接狀態(tài)，需要再回一個(gè)ACK=SYN(s)+1給服務(wù)器，服務(wù)器收到ACK后也進(jìn)入了連接狀態(tài)，這就是一個(gè)三次握手的過程，通過雙方進(jìn)行三次通信保證此時(shí)雙方都已經(jīng)進(jìn)入準(zhǔn)備狀態(tài)。

四次揮手就是在結(jié)束連接的時(shí)候，客戶端會(huì)發(fā)送FIN(c)給服務(wù)器，服務(wù)器收到后回復(fù)客戶端ACK=FIN(c)+1告知客戶端收到客戶端的結(jié)束請求了，這時(shí)客戶端就會(huì)進(jìn)入CLOSING(半關(guān)閉狀態(tài))，等待服務(wù)器的結(jié)束請求。 在一段小延遲時(shí)間后，服務(wù)器也會(huì)發(fā)送一個(gè)FIN(s)請求給客戶端，客戶端收到后發(fā)送ACK=FIN(s)+1給服務(wù)器，服務(wù)器收到ACK后就進(jìn)入結(jié)束狀態(tài)?？蛻舳嗽诘却?個(gè)MSL（避免服務(wù)器收不到ACK）后也進(jìn)入結(jié)束狀態(tài)。

在每次進(jìn)行連接和斷開連接都需要經(jīng)過復(fù)雜的三次握手和四次握手，從而保證了每個(gè)連接都是可靠的，所以TCP協(xié)議是可靠的，而HTTP就是TCP上層的協(xié)議，所有連接都是基于TCP協(xié)議的。
在我們能夠確定每個(gè)請求對應(yīng)的唯一主機(jī)和端口號(hào)，并且通過Http協(xié)議添加響應(yīng)的請求數(shù)據(jù)信息（如模塊名字等）確定請求的代碼位置，并且在每次請求都通過三次握手和四次揮手保證連接的可靠性，所以一個(gè)Http請求是可靠的。

1.6 TCP/IP協(xié)議分為哪幾層？TCP和HTTP分別屬于哪一層？

四層
應(yīng)用層 傳輸層 網(wǎng)絡(luò)層 數(shù)據(jù)鏈路層
http是 應(yīng)用層 tcp 是傳輸層 ip是網(wǎng)絡(luò)層
http 每次請求 需要 三次握手四次揮手

三次握手
第一次 客戶端發(fā)送seq，確定客戶端的發(fā)送能力和服務(wù)端的接收能力
第二次 服務(wù)端返回seq和ack客戶端確認(rèn)了自己的發(fā)送能力和接收能力
第三次 客戶端發(fā)送ack服務(wù)端確定了自己的發(fā)送能力由此進(jìn)行數(shù)據(jù)傳輸

tpc斷開時(shí)需要四次揮手
第一次 客戶端發(fā)送 fin 給服務(wù)端
第二次 服務(wù)端收到，返回ack等于甲乙通話中，甲告訴乙我已經(jīng)說完了，乙說我知道了，然后中間可能還有傳輸內(nèi)容，乙還有話對甲說
第三次 服務(wù)端發(fā)送fin給客戶端
第四次 客戶端發(fā)送ack給服務(wù)端，等于乙告訴甲，我要說的話說完了，甲說知道了, 由此雙方掛斷電話

tcp是基于連接的，所以相對可靠
udp是直接發(fā)送，速度快但是不可靠
tcp可靠基于三次握手和四次揮手，和ack(回執(zhí)機(jī)制) 如果客戶端給服務(wù)端發(fā)送數(shù)據(jù)后沒收到回執(zhí)，會(huì)在一定條件下重復(fù)發(fā)送，并且他們在連接過程中中斷，又會(huì)重新三次握手

http1.1 引入了keepalive機(jī)制，長連接，不必每次請求都是三次握手四次揮手，而是在超時(shí)時(shí)間內(nèi)利用同一個(gè) 連接

http2.0 把基于文本傳輸改為基于二進(jìn)制傳輸和多路復(fù)用

https 是在 http的基礎(chǔ)上加上ssl安全套接字，加入了認(rèn)證加密，增加了一定的安全性,但也不是完全安全，在app中需要將https證書改為嚴(yán)格模式，并且要提前將證書放在客戶端，如果放在服務(wù)端下證書有可能被人抓走，https如果不是嚴(yán)格模式，也是可以進(jìn)行抓包的。