白嫩娇妻被交换经过_被弄出白浆喷水了视频_亚洲依依成人_小蝌蚪视频污下载

　　1. 前言

　　最近很多小伙伴在跳槽面試.

　　在面試中, 面試官說(shuō): 我們做web開發(fā)離不開http協(xié)議, 那么你了解http協(xié)議嗎?

　　大家都答的是了解.

　　然后面試官接著問(wèn)Http協(xié)議是長(zhǎng)連接還是短連接? 如何實(shí)現(xiàn)的?

　　然后小伙伴們就各種支支吾吾的, 這次面試就結(jié)束了........

　　小伙伴既然來(lái)問(wèn)，在這里為大家來(lái)統(tǒng)一講解這個(gè)問(wèn)題.

　　2. 面試題考點(diǎn)

　　如果面試官是千鋒健哥的話, 那么我想考的就是看看候選人對(duì)計(jì)算機(jī)網(wǎng)絡(luò)的了解程度. 基礎(chǔ)是否扎實(shí). 主要考點(diǎn)如下:

　　Http協(xié)議處于OSI網(wǎng)絡(luò)模型的哪一層?

　　Http協(xié)議底層是如何實(shí)現(xiàn)的? 也就是位于傳輸層用的是什么協(xié)議?

　　Http協(xié)議到底是長(zhǎng)連接還是短連接?

　　TCP協(xié)議的三次握手和四次揮手過(guò)程?

　　3. 解題分析

　　下面來(lái)帶大家一起分析下這個(gè)問(wèn)題的解題思路:

　　3.1. HTTP協(xié)議與TCP/IP協(xié)議的關(guān)系

　　HTTP的長(zhǎng)連接和短連接本質(zhì)上是TCP長(zhǎng)連接和短連接。HTTP屬于應(yīng)用層協(xié)議，在傳輸層使用TCP協(xié)議，在網(wǎng)絡(luò)層使用IP協(xié)議。IP協(xié)議主要解決網(wǎng)絡(luò)路由和尋址問(wèn)題，TCP協(xié)議主要解決如何在IP層之上可靠的傳遞數(shù)據(jù)包，使在網(wǎng)絡(luò)上的另一端收到發(fā)端發(fā)出的所有包，并且順序與發(fā)出順序一致。TCP有可靠，面向連接的特點(diǎn)。

　　3.2. 如何理解HTTP協(xié)議是無(wú)狀態(tài)的

　　HTTP協(xié)議是無(wú)狀態(tài)的，指的是協(xié)議對(duì)于事務(wù)處理沒有記憶能力，服務(wù)器不知道客戶端是什么狀態(tài)。也就是說(shuō)，打開一個(gè)服務(wù)器上的網(wǎng)頁(yè)和你之前打開這個(gè)服務(wù)器上的網(wǎng)頁(yè)之間沒有任何聯(lián)系。HTTP是一個(gè)無(wú)狀態(tài)的面向連接的協(xié)議，無(wú)狀態(tài)不代表HTTP不能保持TCP連接，更不能代表HTTP使用的是UDP協(xié)議(無(wú)連接)。

　　3.3. 什么是長(zhǎng)連接、短連接?

　　在HTTP/1.0中，默認(rèn)使用的是短連接。也就是說(shuō)，瀏覽器和服務(wù)器每進(jìn)行一次HTTP操作，就建立一次連接，但任務(wù)結(jié)束就中斷連接。如果客戶端瀏覽器訪問(wèn)的某個(gè)HTML或其他類型的 Web頁(yè)中包含有其他的Web資源，如JavaScript文件、圖像文件、CSS文件等;當(dāng)瀏覽器每遇到這樣一個(gè)Web資源，就會(huì)建立一個(gè)HTTP會(huì)話。

　　但從 HTTP/1.1起，默認(rèn)使用長(zhǎng)連接，用以保持連接特性。使用長(zhǎng)連接的HTTP協(xié)議，會(huì)在響應(yīng)頭有加入這行代碼：Connection:keep-alive

　　在使用長(zhǎng)連接的情況下，當(dāng)一個(gè)網(wǎng)頁(yè)打開完成后，客戶端和服務(wù)器之間用于傳輸HTTP數(shù)據(jù)的 TCP連接不會(huì)關(guān)閉，如果客戶端再次訪問(wèn)這個(gè)服務(wù)器上的網(wǎng)頁(yè)，會(huì)繼續(xù)使用這一條已經(jīng)建立的連接。Keep-Alive不會(huì)永久保持連接，它有一個(gè)保持時(shí)間，可以在不同的服務(wù)器軟件(如Apache)中設(shè)定這個(gè)時(shí)間。實(shí)現(xiàn)長(zhǎng)連接要客戶端和服務(wù)端都支持長(zhǎng)連接。

　　3.4. HTTP協(xié)議的長(zhǎng)連接和短連接，實(shí)質(zhì)上是TCP協(xié)議的長(zhǎng)連接和短連接。

　　TCP連接 當(dāng)網(wǎng)絡(luò)通信時(shí)采用TCP協(xié)議時(shí)，在真正的讀寫操作之前，server與client之間必須建立一個(gè)連接，當(dāng)讀寫操作完成后，雙方不再需要這個(gè)連接時(shí)它們可以釋放這個(gè)連接，連接的建立是需要3次握手的，而釋放則需要4次揮手，所以說(shuō)每個(gè)連接的建立都是需要資源消耗和時(shí)間消耗.

　　三次握手建立連接 , 四次揮手關(guān)閉連接短連接的操作步驟是：建立連接—>數(shù)據(jù)傳輸—>關(guān)閉連接 ... 建立連接—>數(shù)據(jù)傳輸—>關(guān)閉連接長(zhǎng)連接的操作步驟是：建立連接—>數(shù)據(jù)傳輸 ...(保持連接)... 數(shù)據(jù)傳輸—>關(guān)閉連接

　　3.5. tcp三次握手四次揮手過(guò)程

　　先向HTTP服務(wù)器發(fā)起TCP的確認(rèn)請(qǐng)求(三次握手)客戶端 --> SYN --> 服務(wù)器服務(wù)器 --> SYN+ACK --->客戶端客戶端 --> ACK --> 服務(wù)器

　　客戶端要和服務(wù)器斷開TCP連接(四次揮手)客戶端 --> FIN +ACK ---> 服務(wù)器服務(wù)器 --> FIN ---> 客戶端服務(wù)器 --> ACK --> 客戶端客戶端 --> ACK ---> 服務(wù)器

　　4. 總結(jié)

　　經(jīng)過(guò)上面的分析最后千鋒健哥來(lái)給大家總結(jié)下這個(gè)問(wèn)題的完整答案 :

　　Http協(xié)議是長(zhǎng)連接還是短連接看協(xié)議版本, Http1.0是默認(rèn)短連接, Http1.1是默認(rèn)長(zhǎng)連接.

　　Http協(xié)議位于OSI網(wǎng)絡(luò)模型的應(yīng)用層

　　Http協(xié)議底層在傳輸層上使用的是TCP協(xié)議, 在網(wǎng)絡(luò)層使用的是IP協(xié)議. TCP協(xié)議具有三次握手四次揮手過(guò)程, 傳輸數(shù)據(jù)安全穩(wěn)定.