*1.描述下網頁一個 Http 請求，到後端的整個請求過程:

https://blog.csdn.net/w372426096/article/details/82012229

瀏覽器輸入https:www.koolearn.com這個URL，瀏覽器只知道名字是www.koolearn.com,但不知道具體的放完地址，名稱只是方便記；首先使用“地址薄”協議DNS或精準的HTTPDNS查詢，最終會找到IP地址，也就是網際網路世界裡的門牌號。知道地址，瀏覽器開始打包請求，使用Http協議或者加密傳輸Https協議。DNS，HTTP，HTTPS所在層都是應用層，通過socket變成傳輸下一層傳輸層。

傳輸層有TCP和UDP兩種連線協議，傳輸層封裝後，瀏覽器會將包交給作業系統的網路層。

網路層協議是IP協議（包含瀏覽器所在機器的 IP 地址和目標 IP 地址），作業系統知道目標IP地址，就可以找到目標機器；目標又分國內國外，國外通過閘道器；本地地址是mac地址。

作業系統將 IP 包交給了下一層，也就是MAC 層。網絡卡再將包發出，因為有mac地址所以能夠到達閘道器。閘道器收到包後，會根據自己的判斷能力進行下一步，閘道器往往是一個路由器，一層一關知道找到目標伺服器

擴充套件：

當網路包到達一個城關的時候，可以通過路由表得到下一個城關的IP 地址，直接通過 IP 地址找就可以了，為什麼還要通過

本地的 MAC 地址呢？

1.區域網內IP地址是動態分配的，假如我是192.168.2.100，如果我下線了，可能IP就分配給了另一臺電腦。IP和裝置並不總是對應的，這對通訊就產生了問題，但是MAC地址不同，MAC地址和裝置是一一對應且全球唯一的。所以區域網使用MAC地址通訊沒有問題。2.歷史遺留問題：早期的乙太網只有交換機，沒有路由器，乙太網內通過MAC地址通訊。後來才有了網際網路，為了相容原本的模式，採用了IP+MAC地址通訊的方式。為啥不推到了重來呢？看看IPv6的處境你就知道了。所以是先有MAC地址後有的IP，IP的提出主要還是因為MAC地址本身的缺陷，這個問題換成有了MAC為何還要IP地址也很有意思。3.我這裡簡單說一下第一：MAC地址本身的缺陷：因為MAC地址是硬體提供商寫在網絡卡中的，MAC地址雖然唯一但是不能表明使用者在整個網際網路中的位置，除非維護一個超級大MAC地址對應表，那定址效率肯定爆炸。但是IP地址解決了這個問題，因為IP地址是網路提供商給你的，所以你在哪裡整個網路都是知道的。第二：安全問題：獲取MAC地址是通過ARP協議來完成的，如果只用MAC地址通訊，那麼廣播風暴是個難題。4.那麼我覺得如果哪天每人一個固定的IPv6地址，那麼我覺得MAC地址+IPv4的模式是不是可以被替換了？

2.有比較過 Http 和 RPC 嗎？

1.rpc只是一種概念，實現rpc的方式有很多種，但本質上都需要客戶端和服務端之間有一個通訊協議，這個協議用於規範兩個程序通過網路傳輸資料時資料的格式，一邊按照協議把資料裝配好通過網路傳輸，另一邊按照協議把接收的二進位制資料翻譯成有用的資料，這個協議一定是兩端商量好使用同一種的。也就是類似兩個人交流，需要一個雙方都懂的語言，一邊說漢語一邊說英語肯定是無法提供交流的，兩邊都說同一種話才能交流，一邊通過語言的定義把他要表達的意圖/想法轉換成文字/發音提交給另一方，另一方通過語言的定義，在大腦中將文字翻譯為真正要表達的東西。

2.並且協議是不可能沒有的

，比如就算你用Java的序列化方式來傳輸資料，那也是按Java序列化規範了資料格式，那也是一種兩端都協定好的協議；亦或是你自己實現了某種傳輸的資料的格式，通訊的兩端都可以用你的規範下編寫的編解碼工具來處理/翻譯資料，這也是一種協議。就好像原始人交流，通過呃呃啊啊幾個簡單音節配以手舞足蹈的動作，這種“語言”雖然簡陋，但也實現了交流的目的，那他就是原始人的語言。

3.所以這個協議可以是soap協議，也可以是http協議，你不能說用http協議交流的遠端過程呼叫就不算rpc了，用什麼協議是服務端和客戶端在開發時決定的，本質上是實現rpc，只是每個協議都有其自己的特性，不同的協議之間，會有一些比較大的區別，差異比較大的一個例子，比如說利用Json傳輸資料，翻譯和構造都非常耗時，資料也很大，優點是開發人員友好，資料可讀性強，除錯方便，而使用Hession、protobuf，資料處理快，可讀性差，優點就是快，但這個快體現在資料量小、處理快，和網路沒有關係。

4.綜上，RPC和HTTP根本不是一個層面的東西

最後，我看了上面的回答，有好幾個問題不明白，有的人把http協議和tcp協議並列起來談，這兩個不是一個上一個下嗎，沒有tcp協議，哪來的http協議？有的說“自定義tcp協議”，是表達錯誤嗎？是想說“基於tcp協議傳輸的自定義協議”嗎？有的說HTTP開銷在連線的建立與斷開上，難道其他RPC協議不走TCP嗎？HTTP也是可以實現長連線的吧，再不濟，拋去第三方的實現，自己實現一個基於HTTP協議的通訊工具，每次互動忽視HTTP頭關於連線的部分，永遠是長連線，只是把HTTP協議作為資料交流的協議不也OK嗎。

良好的rpc呼叫是面向服務的封裝，針對服務的可用性和效率等都做了優化。單純使用http呼叫則缺少了這些特性。

https://www.jianshu.com/p/5b90a4e70783
3.HttpClient 你說說裡面的具體實現吧？（涉及了哪些東西）

https://blog.csdn.net/w372426096/article/details/82713315
4.那要你設計一個高效能的 Http ，你會怎麼設計？（後續再補充）

【高效能HTTP應用的策略】 

所以，當我們需要一個高效能的HTTP介面型應用時：

1、伺服器端：關閉KeepAlive。

2、伺服器端：最好直接支援HTTP協議（注意用POST，不要GET）,而不是任何包裝過的協議，比如：hessian/soap等。

3、伺服器端：在一個請求中，最好設計成：支援多條指令批處理，以節省連線數。

4、伺服器端：對請求的處理應當儘可能的快（如在150ms內）。

5、客戶端：在程式碼中，同一個客戶端例項中全部請求結束後應主動關閉連線（無須事先設定客戶端的ConnectionTimeOut引數）。

6、客戶端：如伺服器未關閉KeepAlive，在同一個客戶端例項中可以適量發出多個請求（總時間應稍小於伺服器KeepAliveTimeout引數）。此方式需要精確操作，不推薦。

最後，在介面設計上，對於一些非同步操作，儘量不要設計成單方面輪詢模式（減少大量無謂請求數），應設計成被呼叫方的非同步結果回撥模式。

【一些優化細節】

在伺服器端，我們一般選用的是Apache+Tomcat/JBoss的組合。關於JBoss的配置及優化可參看JBoss官網。

最主要的是關於Apache的優化，推薦閱讀兩篇文章：
1、Apache效能優化：http://www.aliwo.net:8080/2009/12/apache/

2、Apache中KeepAlive配置的合理使用：http://www.net527.cn/a/caozuoxitong/Linux/5283.html

在客戶端的Java程式碼中，我們最常使用的是HttpClient工具包。

有一些細節要注意：

1、在每一個HttpClient例項發完請求後，（如不再使用）應及時關閉連線。

最簡單的方式是，在HTTP Request Header中傳送(Connection: close)，指示伺服器關閉當前連線。

程式碼如下：

method.setRequestHeader("Connection", "close");

2、可以設計為單例模式：無需每次建立HttpClient例項，可多次傳送請求

參考：http://seanhe.iteye.com/blog/234759

5.TCP 和 UDP 的區別？TCP 資料傳輸過程中怎麼做到可靠的？

傳輸層有兩個性質不同的協議：TCP（Transmission ControlProtocol，傳輸控制協議）和 UDP（User Data Protocol，⽤戶資料報協
議）。

TCP與UDP區別總結：

1、TCP面向連線（如打電話要先撥號建立連線）;UDP是無連線的，即傳送資料之前不需要建立連線

2、TCP提供可靠的服務。也就是說，通過TCP連線傳送的資料，無差錯，不丟失，不重複，且按序到達;UDP盡最大努力交付，即不保證可靠交付
3、TCP面向位元組流，實際上是TCP把資料看成一連串無結構的位元組流;UDP是面向報文的
UDP沒有擁塞控制，因此網路出現擁塞不會使源主機的傳送速率降低（對實時應用很有用，如IP電話，實時視訊會議等）
4、每一條TCP連線只能是點到點的;UDP支援一對一，一對多，多對一和多對多的互動通訊
5、TCP首部開銷20位元組;UDP的首部開銷小，只有8個位元組

6、TCP的邏輯通訊通道是全雙工的可靠通道，UDP則是不可靠通道

UDP實現可靠傳輸：

由於在傳輸層UDP已經是不可靠的連線，那就要在應用層自己實現一些保障可靠傳輸的機制

簡單來講，要使用UDP來構建可靠的面向連線的資料傳輸，就要實現類似於TCP協議的

超時重傳（定時器）

有序接受 （新增包序號）

應答確認 （Seq/Ack應答機制）

滑動視窗流量控制等機制 （滑動視窗協議）

等於說要在傳輸層的上一層（或者直接在應用層）實現TCP協議的可靠資料傳輸機制，比如使用UDP資料包+序列號，UDP資料包+時間戳等方法。

目前已經有一些實現UDP可靠傳輸的機制，比如UDT

TCP 實現可靠傳輸

通過三次握手連線，四次揮手斷開的機制

6.三次握手和四次揮手、為什麼揮手需要四次

https://blog.csdn.net/w372426096/article/details/81836919
7.http 預設埠，https 預設埠

HTTP協議代理伺服器常用埠號：80/8080/3128/8081/9098

HTTPS（securely transferring web pages）伺服器，預設埠號為443/tcp  443/udp

TOMCAT，預設埠號為8080
8.DNS 你知道是幹嘛的嗎？

DNS域名系統：解析域名，每個ip地址都可以有一個主機名，主機名由一個或多個字串組成，字串之間用小數點隔開。有了主機名，就不要死記硬背每臺IP裝置的IP地址，只要記住相對直觀有意義的主機名就行了。這就是DNS協議的功能。
9.計算機網路七層模型。

10.什麼是長連線和短連線

在HTTP/1.0中預設使用短連線。也就是說，客戶端和伺服器每進行一次HTTP操作，就建立一次連線，任務結束就中斷連線。當客戶端瀏覽器訪問的某個HTML或其他型別的Web頁中包含有其他的Web資源（如JavaScript檔案、影象檔案、CSS檔案等），每遇到這樣一個Web資源，瀏覽器就會重新建立一個HTTP會話。

而從HTTP/1.1起，預設使用長連線，用以保持連線特性。使用長連線的HTTP協議，會在響應頭加入這行程式碼：

Connection:keep-alive

在使用長連線的情況下，當一個網頁開啟完成後，客戶端和伺服器之間用於傳輸HTTP資料的TCP連線不會關閉，客戶端再次訪問這個伺服器時，會繼續使用這一條已經建立的連線。Keep-Alive不會永久保持連線，它有一個保持時間，可以在不同的伺服器軟體（如Apache）中設定這個時間。實現長連線需要客戶端和服務端都支援長連線。

HTTP協議的長連線和短連線，實質上是TCP協議的長連線和短連線。

長連線可以省去較多的TCP建立和關閉的操作，減少浪費，節約時間。Client與server之間的連線如果一直不關閉的話，會存在一個問題，隨著客戶端連線越來越多，server早晚有扛不住的時候，這時候server端需要採取一些策略，如關閉一些長時間沒有讀寫事件發生的連線，這樣可以避免一些惡意連線導致server端服務受損；如果條件再允許就可以以客戶端機器為顆粒度，限制每個客戶端的最大長連線數，這樣可以完全避免某個蛋疼的客戶端連累後端服務。

短連線對於伺服器來說管理較為簡單，存在的連線都是有用的連線，不需要額外的控制手段。但如果客戶請求頻繁，將在TCP的建立和關閉操作上浪費時間和頻寬。

長連線多用於操作頻繁，點對點的通訊，而且連線數不能太多情況。每個TCP連線都需要三步握手，這需要時間，如果每個操作都是先連線，再操作的話那麼處理速度會降低很多，所以每個操作完後都不斷開，次處理時直接傳送資料包就OK，不用建立TCP連線。例如：資料庫的連線用長連線， 如果用短連線頻繁的通訊會造成socket錯誤，而且頻繁的socket 建立也是對資源的浪費。
而像WEB網站的http服務一般都用短連結，因為長連線對於服務端來說會耗費一定的資源，而像WEB網站這麼頻繁的成千上萬甚至上億客戶端的連線用短連線會更省一些資源，如果用長連線，而且同時有成千上萬的使用者，如果每個使用者都佔用一個連線的話，那可想而知吧。所以併發量大，但每個使用者無需頻繁操作情況下需用短連好。

http://blog.jobbole.com/104108/
11.Http1.0和2.0相比有什麼區別，可參考《Http 2.0》

https://blog.csdn.net/w372426096/article/details/81282071
12.Https的基本概念

HTTPS (基於安全套接字層的超文字傳輸協議 或者是 HTTP over SSL) 是一個 Netscape 開發的 Web 協議。

可以說：HTTPS = HTTP + SSL；HTTPS 在 HTTP 應用層的基礎上使用安全套接字層作為子層。

為什麼需要 HTTPS ？

超文字傳輸協議 (HTTP) 是一個用來通過網際網路傳輸和接收資訊的協議。HTTP 使用請求/響應的過程，因此資訊可在伺服器間快速、輕鬆而且精確的進行傳輸。當你訪問 Web 頁面的時候你就是在使用 HTTP 協議，但 HTTP 是不安全的，可以輕鬆竊聽你跟 Web 伺服器之間的資料傳輸。在很多情況下，客戶和伺服器之間傳輸的是敏感資訊，需要防止未經授權的訪問。為了滿足這個要求，網景公司(Netscape)推出了 HTTPS，也就是基於安全套接字層的 HTTP 協議。

HTTP 和 HTTPS 的相同點

大多數情況下，HTTP 和 HTTPS 是相同的，因為都是採用同一個基礎的協議，作為 HTTP 或 HTTPS 客戶端——瀏覽器，設立一個連線到 Web 伺服器指定的埠。當伺服器接收到請求，它會返回一個狀態碼以及訊息，這個迴應可能是請求資訊或者指示某個錯誤傳送的錯誤資訊。系統使用統一資源定位器 URI 模式，因此資源可以被唯一指定。而 HTTPS 和 HTTP 唯一不同的只是一個協議頭(https)的說明，其他都是一樣的。

HTTP 和 HTTPS 的不同之處

1. HTTP 的 URL 以 http:// 開頭，而 HTTPS 的 URL 以 https:// 開頭
2. HTTP 是不安全的，而 HTTPS 是安全的
3. HTTP 標準埠是 80 ，而 HTTPS 的標準埠是 443
4. 在 OSI 網路模型中，HTTP 工作於應用層，而 HTTPS 工作在傳輸層
5. HTTP 無需加密，而 HTTPS 對傳輸的資料進行加密
6. HTTP 無需證書，而 HTTPS 需要認證證書

HTTPS 如何工作?

使用 HTTPS 連線時，伺服器要求有公鑰和簽名的證書。

當使用 https 連線，伺服器響應初始連線，並提供它所支援的加密方法。作為迴應，客戶端選擇一個連線方法，並且客戶端和伺服器端交換證書驗證彼此身份。完成之後，在確保使用相同金鑰的情況下傳輸加密資訊，然後關閉連線。為了提供 https 連線支援，伺服器必須有一個公鑰證書，該證書包含經過證書機構認證的金鑰資訊，大部分證書都是通過第三方機構授權的，以保證證書是安全的。

換句話說，HTTPS 跟 HTTP 一樣，只不過增加了 SSL。

HTTP 包含如下動作：

1. 瀏覽器開啟一個 TCP 連線
2. 瀏覽器傳送 HTTP 請求到伺服器端
3. 伺服器傳送 HTTP 迴應資訊到瀏覽器
4. TCP 連線關閉

SSL 包含如下動作：

1. 驗證伺服器端
2. 允許客戶端和伺服器端選擇加密演算法和密碼，確保雙方都支援
3. 驗證客戶端(可選)
4. 使用公鑰加密技術來生成共享加密資料
5. 建立一個加密的 SSL 連線
6. 基於該 SSL 連線傳遞 HTTP 請求

什麼時候該使用 HTTPS?

銀行網站、支付閘道器、購物網站、登入頁、電子郵件以及一些企業部門的網站應該使用 HTTPS，例如：

13.http協議格式，get和post的區別

GET	POST
後退按鈕/重新整理	無害	資料會被重新提交（瀏覽器應該告知使用者資料會被重新提交）。
書籤	可收藏為書籤	不可收藏為書籤
快取	能被快取	不能快取
編碼型別	application/x-www-form-urlencoded	application/x-www-form-urlencoded 或 multipart/form-data。為二進位制資料使用多重編碼。
歷史	引數保留在瀏覽器歷史中。	引數不會儲存在瀏覽器歷史中。
對資料長度的限制	是的。當傳送資料時，GET 方法向 URL 新增資料；URL 的長度是受限制的（URL 的最大長度是 2048 個字元）。	無限制。
對資料型別的限制	只允許 ASCII 字元。	沒有限制。也允許二進位制資料。
安全性	與 POST 相比，GET 的安全性較差，因為所傳送的資料是 URL 的一部分。 在傳送密碼或其他敏感資訊時絕不要使用 GET ！	POST 比 GET 更安全，因為引數不會被儲存在瀏覽器歷史或 web 伺服器日誌中。
可見性	資料在 URL 中對所有人都是可見的。	資料不會顯示在 URL 中。

1. GET提交的資料會放在URL之後，以?分割URL和傳輸資料，引數之間以&相連，如EditPosts.aspx?name=test1&id=123456.POST方法是把提交的資料放在HTTP包的Body中.

2. GET方式需要使用Request.QueryString來取得變數的值，而POST方式通過Request.Form來獲取變數的值。