国产像蕉9,手机免费在线观看AV网站,久久久久久成人影片,久草网大香蕉,五月激情婷婷中文字幕,色婷婷在线无码精品秘人口传媒,亚州操逼图,亚洲免费在线视频观看

面試常見

一道經(jīng)典的面試題

還記得這道經(jīng)典的面試題目嗎？從 URL 在瀏覽器被被輸入到頁面展現(xiàn)的過程中發(fā)生了什么？

總體來說分為以下幾個過程:

DNS 解析:將域名解析成 IP 地址
TCP 連接：TCP 三次握手
發(fā)送 HTTP 請求
服務(wù)器處理請求并返回 HTTP 報文
瀏覽器解析渲染頁面
斷開連接：TCP 四次揮手

完整的可以看以下下面的圖片

http 必備基礎(chǔ)知識

HTTP 是一種超文本傳輸協(xié)議(Hypertext Transfer Protocol)，HTTP 是一個在計算機世界里專門在兩點之間傳輸文字、圖片、音頻、視頻等超文本數(shù)據(jù)的約定和規(guī)范

HTTP 主要內(nèi)容分為三部分，超文本（Hypertext）、傳輸（Transfer）、協(xié)議（Protocol）。

超文本就是不單單只是本文，它還可以傳輸圖片、音頻、視頻，甚至點擊文字或圖片能夠進行超鏈接的跳轉(zhuǎn)。
上面這些概念可以統(tǒng)稱為數(shù)據(jù)，傳輸就是數(shù)據(jù)需要經(jīng)過一系列的物理介質(zhì)從一個端系統(tǒng)傳送到另外一個端系統(tǒng)的過程。通常我們把傳輸數(shù)據(jù)包的一方稱為請求方，把接到二進制數(shù)據(jù)包的一方稱為應(yīng)答方。
而協(xié)議指的就是是網(wǎng)絡(luò)中(包括互聯(lián)網(wǎng))傳遞、管理信息的一些規(guī)范。如同人與人之間相互交流是需要遵循一定的規(guī)矩一樣，計算機之間的相互通信需要共同遵守一定的規(guī)則，這些規(guī)則就稱為協(xié)議，只不過是網(wǎng)絡(luò)協(xié)議。

什么是無狀態(tài)協(xié)議，HTTP 是無狀態(tài)協(xié)議嗎，怎么解決

無狀態(tài)協(xié)議(Stateless Protocol) 就是指瀏覽器對于事務(wù)的處理沒有記憶能力。舉個例子來說就是比如客戶請求獲得網(wǎng)頁之后關(guān)閉瀏覽器，然后再次啟動瀏覽器，登錄該網(wǎng)站，但是服務(wù)器并不知道客戶關(guān)閉了一次瀏覽器。

HTTP 就是一種無狀態(tài)的協(xié)議，他對用戶的操作沒有記憶能力。可能大多數(shù)用戶不相信，他可能覺得每次輸入用戶名和密碼登陸一個網(wǎng)站后，下次登陸就不再重新輸入用戶名和密碼了。這其實不是 HTTP 做的事情，起作用的是一個叫做小甜餅(Cookie) 的機制。它能夠讓瀏覽器具有記憶能力。
如果你的瀏覽器允許 cookie 的話，查看方式 chrome://settings/content/cookies

幾種方法

HTTP1.0定義了三種請求方法：GET, POST 和 HEAD方法

HTTP1.1新增了五種請求方法：OPTIONS, PUT, DELETE, TRACE 和 CONNECT

GET: 通常用于請求服務(wù)器發(fā)送某些資源
HEAD: 請求資源的頭部信息, 并且這些頭部與 HTTP GET 方法請求時返回的一致. 該請求方法的一個使用場景是在下載一個大文件前先獲取其大小再決定是否要下載, 以此可以節(jié)約帶寬資源
OPTIONS: 用于獲取目的資源所支持的通信選項
POST: 發(fā)送數(shù)據(jù)給服務(wù)器，是非冪等的
PUT: 跟POST方法很像，也是想服務(wù)器提交數(shù)據(jù)。但是，它們之間有不同。PUT指定了資源在服務(wù)器上的位置，而POST不需要置頂資源在服務(wù)器的位置，是冪等的
DELETE: 用于刪除指定的資源
PATCH: 用于對資源進行部分修改
CONNECT: HTTP/1.1協(xié)議中預(yù)留給能夠?qū)⑦B接改為管道方式的代理服務(wù)器
TRACE: 回顯服務(wù)器收到的請求，主要用于測試或診斷

http get 和 post 區(qū)別

Post一般用于更新或者添加資源信息

Get一般用于查詢操作，而且應(yīng)該是安全和冪等的


Post更加安全	Get會把請求的信息放到URL的后面
Post傳輸量一般無大小限制	Get不能大于2KB
Post執(zhí)行效率低	Get執(zhí)行效率略高

http put 和 post 區(qū)別

舉一個簡單的例子

POST:用于提交請求，可以更新或者創(chuàng)建資源，是非冪等的

舉個例子，在我們的支付系統(tǒng)中，一個api的功能是創(chuàng)建收款金額二維碼，它和金額相關(guān)，每個用戶可以有多個二維碼，如果連續(xù)調(diào)用則會創(chuàng)建新的二維碼，這個時候就用POST

PUT: 用于向指定的URI傳送更新資源，是冪等的

還是那個例子，用戶的賬戶二維碼只和用戶關(guān)聯(lián)，而且是一一對應(yīng)的關(guān)系，此時這個api就可以用PUT，因為每次調(diào)用它，都將刷新用戶賬戶二維碼

如果從 RESTful API 的角度來理解，PUT 方法是這么工作的：

把一個對象 V 綁定到地址 K 上；今后請求地址 K 時，就會返回對象 V。

如果地址 K 之前曾綁定過另一個對象，比如 V0，那么 V0 會被 V 替換。

舉一個簡單的例子，假設(shè)我的博客后臺支持 RESTful API，我可以通過下面的請求發(fā)布這篇文章：

1PUT?https://gdutxiao.github.io/2018/04/16/http-put-vs-post?HTTP/1.1
2
3{
4????/*?文章內(nèi)容正文?*/
5}

可以看出，使用 PUT 方法時，客戶端需要在 HTTP 請求中明確指定地址 K。

正如 Java 的例子一樣，PUT 方法應(yīng)當支持冪等性。如果是同一個對象 V，PUT 多次與 PUT 一次返回的結(jié)果應(yīng)該是相同的。客戶端可以利用 PUT 的冪等性安全地重試請求，保證客戶端的請求至少被服務(wù)端處理一次。

如果把上面發(fā)布文章的例子用 HTTP POST 方法重寫，它可能會是下面這樣：

1POST?https://gdutxiao.github.io/post-article?HTTP/1.1
2
3{
4????/*?文章內(nèi)容正文?*/
5}

也就是說，地址 K 不是由客戶端指定的，而是由服務(wù)端生成的。比如，服務(wù)端可能會根據(jù)日期和文章標題，為本文分配一個地址。

另外，與 PUT 方法不同，POST 方法是不支持冪等性的。同一個請求被處理兩次，應(yīng)當生成兩份對象。換句話說，客戶端應(yīng)該只發(fā)送一次 POST 請求，而客戶端的請求至多會被服務(wù)端處理一次。

現(xiàn)在問題來了，如果真的遇到了網(wǎng)絡(luò)故障，客戶端應(yīng)該如何重試 POST 請求呢？解決方法其實很簡單，我們可以在 POST 請求中隱藏一個唯一的 token，服務(wù)端在處理請求后把 token 存入數(shù)據(jù)庫，如果這個 token 之前遇到過，服務(wù)端就知道這是重復(fù)的 POST 請求，可以不再處理了。

http 版本

1.0 與 1.1

http1.0一次只能處理一個請求，不能同時收發(fā)數(shù)據(jù)
http1.1可以處理多個請求，能同時收發(fā)數(shù)據(jù)
http1.1增加可更多字段，如cache-control,keep-alive.

2.0

http 2.0采用二進制的格式傳送數(shù)據(jù)，不再使用文本格式傳送數(shù)據(jù)
http2.0對消息頭采用hpack壓縮算法，http1.x的版本消息頭帶有大量的冗余消息
http2.0 采用多路復(fù)用，即用一個tcp連接處理所有的請求，真正意義上做到了并發(fā)請求，流還支持優(yōu)先級和流量控制（HTTP/1.x 雖然通過 pipeline也能并發(fā)請求，但是多個請求之間的響應(yīng)會被阻塞的，所以 pipeline 至今也沒有被普及應(yīng)用，而 HTTP/2 做到了真正的并發(fā)請求。同時，流還支持優(yōu)先級和流量控制。）
http2.0支持server push，服務(wù)端可以主動把css，jsp文件主動推送到客戶端，不需要客戶端解析HTML，再發(fā)送請求，當客戶端需要的時候，它已經(jīng)在客戶端了。

缺點

雖然 HTTP/2 解決了很多之前舊版本的問題，但是它還是存在一個巨大的問題，?主要是底層支撐的 TCP 協(xié)議造成的
。HTTP/2的缺點主要有以下幾點：

TCP 以及 TCP+TLS建立連接的延時

HTTP/2使用TCP協(xié)議來傳輸?shù)模绻褂肏TTPS的話，還需要使用TLS協(xié)議進行安全傳輸，而使用TLS也需要一個握手過程，
這樣就需要有兩個握手延遲過程?：

①在建立TCP連接的時候，需要和服務(wù)器進行三次握手來確認連接成功，也就是說需要在消耗完1.5個RTT之后才能進行數(shù)據(jù)傳輸。

②進行TLS連接，TLS有兩個版本——TLS1.2和TLS1.3，每個版本建立連接所花的時間不同，大致是需要1~2個RTT。

總之，在傳輸數(shù)據(jù)之前，我們需要花掉 3～4 個 RTT。

TCP的隊頭阻塞并沒有徹底解決

上文我們提到在HTTP/2中，多個請求是跑在一個TCP管道中的。但當出現(xiàn)了丟包時，HTTP/2 的表現(xiàn)反倒不如 HTTP/1
了。因為TCP為了保證可靠傳輸，有個特別的“丟包重傳”機制，丟失的包必須要等待重新傳輸確認，HTTP/2出現(xiàn)丟包時，整個 TCP
都要開始等待重傳，那么就會阻塞該TCP連接中的所有請求（如下圖）。而對于 HTTP/1.1 來說，可以開啟多個 TCP
連接，出現(xiàn)這種情況反到只會影響其中一個連接，剩余的 TCP 連接還可以正常傳輸數(shù)據(jù)。

Http 3.0

Google 在推SPDY的時候就已經(jīng)意識到了這些問題，于是就另起爐灶搞了一個基于 UDP 協(xié)議的“QUIC”協(xié)議，讓HTTP跑在QUIC上而不是TCP上。
而這個“HTTP over QUIC”就是HTTP協(xié)議的下一個大版本，HTTP/3。它在HTTP/2的基礎(chǔ)上又實現(xiàn)了質(zhì)的飛躍，真正“完美”地解決了“隊頭阻塞”問題。

QUIC 雖然基于 UDP，但是在原本的基礎(chǔ)上新增了很多功能，接下來我們重點介紹幾個QUIC新功能。不過HTTP/3目前還處于草案階段，正式發(fā)布前可能會有變動，所以本文盡量不涉及那些不穩(wěn)定的細節(jié)。

QUIC新功能

上面我們提到QUIC基于UDP，而UDP是“無連接”的，根本就不需要“握手”和“揮手”，所以就比TCP來得快。此外QUIC也實現(xiàn)了可靠傳輸，保證數(shù)據(jù)一定能夠抵達目的地。它還引入了類似HTTP/2的“流”和“多路復(fù)用”，單個“流"是有序的，可能會因為丟包而阻塞，但其他“流”不會受到影響。具體來說QUIC協(xié)議有以下特點：

實現(xiàn)了類似TCP的流量控制、傳輸可靠性的功能。

雖然UDP不提供可靠性的傳輸，但QUIC在UDP的基礎(chǔ)之上增加了一層來保證數(shù)據(jù)可靠性傳輸。它提供了數(shù)據(jù)包重傳、擁塞控制以及其他一些TCP中存在的特性。

實現(xiàn)了快速握手功能。

由于QUIC是基于UDP的，所以QUIC可以實現(xiàn)使用0-RTT或者1-RTT來建立連接，這意味著QUIC可以用最快的速度來發(fā)送和接收數(shù)據(jù)，這樣可以大大提升首次打開頁面的速度。
0RTT 建連可以說是 QUIC 相比 HTTP2 最大的性能優(yōu)勢?。

集成了TLS加密功能。

目前QUIC使用的是TLS1.3，相較于早期版本TLS1.3有更多的優(yōu)點，其中最重要的一點是減少了握手所花費的RTT個數(shù)。

多路復(fù)用，徹底解決TCP中隊頭阻塞的問題

和TCP不同，QUIC實現(xiàn)了在同一物理連接上可以有多個獨立的邏輯數(shù)據(jù)流（如下圖）。實現(xiàn)了數(shù)據(jù)流的單獨傳輸，就解決了TCP中隊頭阻塞的問題。

關(guān)于 http 3.0 的，如果想了解更多，可以查看這一篇文章。解密HTTP/2與HTTP/3 的新特性

總結(jié)

HTTP/1.1有兩個主要的缺點：安全不足和性能不高。
HTTP/2完全兼容HTTP/1，是“更安全的HTTP、更快的HTTPS"，頭部壓縮、多路復(fù)用等技術(shù)可以充分利用帶寬，降低延遲，從而大幅度提高上網(wǎng)體驗；
QUIC 基于 UDP 實現(xiàn)，是 HTTP/3 中的底層支撐協(xié)議，該協(xié)議基于 UDP，又取了 TCP 中的精華，實現(xiàn)了即快又可靠的協(xié)議

一些經(jīng)典的Http面試題