1.1 請(qǐng)簡(jiǎn)述 Http 與 Https 的區(qū)別？

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

1、https協(xié)議需要到ca申請(qǐng)證書(shū)胎许，一般免費(fèi)證書(shū)較少峻呛，因而需要一定費(fèi)用。
2辜窑、http是超文本傳輸協(xié)議钩述，信息是明文傳輸，https則是具有安全性的ssl加密傳輸協(xié)議穆碎。
3切距、http和https使用的是完全不同的連接方式，用的端口也不一樣惨远，前者是80谜悟，后者是443。
4北秽、http的連接很簡(jiǎn)單葡幸，是無(wú)狀態(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 說(shuō)一說(shuō)https蔑水、udp、socket區(qū)別扬蕊？

https協(xié)議需要到CA申請(qǐng)證書(shū)搀别。

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

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

http的連接很簡(jiǎn)單翎冲，是無(wú)狀態(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：用戶(hù)數(shù)據(jù)報(bào)協(xié)議 （UDP：User DatagramProtocol）
Socket:
這是為了實(shí)現(xiàn)以上的通信過(guò)程而建立成來(lái)通信管道檐春，其真實(shí)的代表是客戶(hù)端和服務(wù)器端的一個(gè)通信進(jìn)程逻淌，雙方進(jìn)程通過(guò)socket進(jìn)行通信，而通信的規(guī)則采用指定的協(xié)議疟暖。
socket只是一種連接模式卡儒，不是協(xié)議，socket是對(duì)TCP/IP協(xié)議的封裝俐巴，Socket本身并不是協(xié)議骨望，而是一個(gè)調(diào)用接口（API），通過(guò)Socket欣舵，我們才能使用TCP/IP協(xié)議擎鸠。
tcp、udp缘圈，簡(jiǎn)單的說(shuō)（雖然不準(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 請(qǐng)簡(jiǎn)述一次http網(wǎng)絡(luò)請(qǐng)求的過(guò)程？

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

postman

1.4 談一談TCP/IP三次握手虐急，四次揮手箱残？

常見(jiàn)的 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)制斷開(kāi)連接
FIN：該位為 1 時(shí)，表示今后不會(huì)再有數(shù)據(jù)發(fā)送敷待，希望斷開(kāi)連接。當(dāng)通信結(jié)束希望斷開(kāi)連接時(shí)仁热，通信雙方的主機(jī)之間就可以相互交換 FIN 位為 1 的 TCP 段

TCP 三次握手

TCP 三次握手

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

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

客戶(hù)端會(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ù)壶硅，之后客戶(hù)端處于 SYN-SENT 狀態(tài)。

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

服務(wù)端收到客戶(hù)端的 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ā)給客戶(hù)端约谈，該報(bào)文也不包含應(yīng)用層數(shù)據(jù)，之后服務(wù)端處于SYN-RCVD 狀態(tài)。

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

客戶(hù)端收到服務(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)文可以攜帶客戶(hù)到服務(wù)器的數(shù)據(jù)，之后客戶(hù)端處于ESTABLISHED 狀態(tài)粪躬。

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

為什么是三次握手吗货？不是兩次泳唠、四次？

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

TCP 四次揮手過(guò)程

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

• 客戶(hù)端打算關(guān)閉連接宙搬，此時(shí)會(huì)發(fā)送一個(gè) TCP 首部 FIN標(biāo)志位被置為 1 的報(bào)文笨腥，也即 FIN 報(bào)文，之后客戶(hù)端進(jìn)入 FIN_WAIT_1 狀態(tài)勇垛。
• 服務(wù)端收到該報(bào)文后脖母，就向客戶(hù)端發(fā)送 ACK 應(yīng)答報(bào)文，接著服務(wù)端進(jìn)入 CLOSED_WAIT 狀態(tài)闲孤。
• 客戶(hù)端收到服務(wù)端的 ACK 應(yīng)答報(bào)文后谆级，之后進(jìn)入FIN_WAIT_2 狀態(tài)。
• 等待服務(wù)端處理完數(shù)據(jù)后讼积，也向客戶(hù)端發(fā)送 FIN 報(bào)文肥照，之后服務(wù)端進(jìn)入 LAST_ACK 狀態(tài)。
• 客戶(hù)端收到服務(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)閉吕朵。
• 客戶(hù)端在經(jīng)過(guò) 2MSL 一段時(shí)間后，自動(dòng)進(jìn)入 CLOSED 狀態(tài)掌桩，至此客戶(hù)端也完成連接的關(guān)閉边锁。

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

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

為什么揮手需要四次？

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

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

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

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

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

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

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

如訪問(wèn)一個(gè)Http請(qǐng)求：http://45.124.252.66:9090/main/
怎么訪問(wèn)到這個(gè)網(wǎng)站呢响逢？
首先我們需要通過(guò)網(wǎng)絡(luò)绒窑，可能是移動(dòng)網(wǎng)或者寬帶網(wǎng)等（這就是物理層，它是一個(gè)傳輸介質(zhì)）舔亭，然后找到對(duì)應(yīng)那一臺(tái)被我們?cè)L問(wèn)的服務(wù)器的mac地址（網(wǎng)絡(luò)訪問(wèn)層）進(jìn)行連接些膨，再匹配它的IP（網(wǎng)絡(luò)互聯(lián)層）是否對(duì)應(yīng)，確定了主機(jī)后钦铺，再通過(guò)端口號(hào)9090（傳輸層）訪問(wèn)對(duì)應(yīng)的進(jìn)程订雾，由于一個(gè)進(jìn)程里面有很多業(yè)務(wù)模塊，而我們需要訪問(wèn)main模塊（應(yīng)用層）矛洞，最終通過(guò)不同層來(lái)實(shí)現(xiàn)網(wǎng)站的訪問(wèn)洼哎。
每個(gè)層都是相互獨(dú)立，并且向下依賴(lài)，而傳輸層是能確定唯一主機(jī)的噩峦，因?yàn)槲覀兛梢酝ㄟ^(guò)mac地址锭沟、host和端口來(lái)確定唯一的一臺(tái)訪問(wèn)主機(jī)上面的進(jìn)程∈恫梗或許有的人會(huì)問(wèn)族淮，那如果網(wǎng)絡(luò)中斷呢？那不就不可靠了嗎凭涂，我們常說(shuō)的網(wǎng)絡(luò)中斷是屬于物理層祝辣，由于是向下依賴(lài)，傳輸層的建立是依賴(lài)于下面的三層（網(wǎng)絡(luò)互聯(lián)層切油、網(wǎng)絡(luò)訪問(wèn)層较幌、物理層）已經(jīng)連接成功，如果下面的層都沒(méi)有連接成功白翻，也就沒(méi)有傳輸層這一說(shuō)了，所以傳輸層協(xié)議是一個(gè)“靠譜”的協(xié)議绢片。

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

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

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

四次揮手就是在結(jié)束連接的時(shí)候等舔，客戶(hù)端會(huì)發(fā)送FIN(c)給服務(wù)器骚灸，服務(wù)器收到后回復(fù)客戶(hù)端ACK=FIN(c)+1告知客戶(hù)端收到客戶(hù)端的結(jié)束請(qǐng)求了，這時(shí)客戶(hù)端就會(huì)進(jìn)入CLOSING(半關(guān)閉狀態(tài))慌植，等待服務(wù)器的結(jié)束請(qǐng)求甚牲。 在一段小延遲時(shí)間后，服務(wù)器也會(huì)發(fā)送一個(gè)FIN(s)請(qǐng)求給客戶(hù)端蝶柿，客戶(hù)端收到后發(fā)送ACK=FIN(s)+1給服務(wù)器丈钙，服務(wù)器收到ACK后就進(jìn)入結(jié)束狀態(tài)〗惶溃客戶(hù)端在等待2個(gè)MSL（避免服務(wù)器收不到ACK）后也進(jìn)入結(jié)束狀態(tài)雏赦。

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

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

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

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

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

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

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

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

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