粗讀《圖解HTTP》(一)

蠻早以前掃過一遍這個圖片生動形象的《圖解HTTP》一書。前段時間開始搗鼓Python,看別人寫的爬蟲,什么請求頭都看不懂。。所以又看了一遍。為方便以后復(fù)習,摘一些我認為的重點出來。

什么是HTTP

HTTP(HyperText Transfer Protocol,超文本傳輸協(xié)議)是Web用來完成從客戶端到服務(wù)器等一系列運作流程的協(xié)議。HTTP是Web通信的基礎(chǔ)。

其實也就是可以理解為,HTTP其實就是一個約定好的通信協(xié)議,HTTP一開始只是一種簡單的協(xié)議,隨著技術(shù)的發(fā)展,需要攜帶的信息也越來越復(fù)雜,就衍生出許多種基于HTTP的附加協(xié)議來達成需求。但是基礎(chǔ)都是HTTP。

TCP/IP

通常使用的網(wǎng)絡(luò)(包括互聯(lián)網(wǎng))實在TCP/IP協(xié)議族的基礎(chǔ)上運作的,所以說TCP/IP是網(wǎng)絡(luò)基礎(chǔ)。HTTP是屬于他的一個子集。

還有不是基于TCP/IP的網(wǎng)絡(luò)?
TCP/IP的作用其實就相當于人的語言,不同設(shè)備通過互聯(lián)網(wǎng)交流信息,必須基于相同的方法來傳輸信息,這個方法一般稱為協(xié)議(protocol)。
TCP/IP協(xié)議族類型
TCP/IP的分層管理

TCP/IP協(xié)議族按層次可以分為以下4層:應(yīng)用層、傳輸層、網(wǎng)絡(luò)層、數(shù)據(jù)鏈路層。

分層其實就是一個封裝思想的體現(xiàn),各個層實現(xiàn)并完成不同的功能,再傳輸給其他層,各層之間相對獨立,需要替換掉某一層不需要整體替換,只需要實現(xiàn)該層應(yīng)實現(xiàn)的功能即可。

#######應(yīng)用層
應(yīng)用層決定了向用戶提供服務(wù)時通信的活動。TCP/IP協(xié)議族內(nèi)預(yù)存了各類通信的應(yīng)用服務(wù),比如FTP和DNS。HTTP也處于該層。
#######傳輸層


#######網(wǎng)絡(luò)層


#######鏈路層

TCP/IP通信傳輸流
TCP/IP通信傳輸流

通信流簡單來說就是,為了保證數(shù)據(jù)的送達,發(fā)送端經(jīng)過四層封裝,接收端通過四層解析,最終得到消息本體。
書里以HTTP舉了個栗子。

HTTP請求發(fā)送接收舉例
這里我覺得需要記一下經(jīng)過各層之后的數(shù)據(jù)名稱,HTTP報文-->TCP首部-->IP數(shù)據(jù)包-->網(wǎng)絡(luò)架構(gòu)。發(fā)送到網(wǎng)絡(luò)上的數(shù)據(jù)包形式從外往內(nèi)分別是以太網(wǎng)首部、IP首部、TCP首部、HTTP報文。
這種處理方式其實可以理解成古代的飛鴿傳書。家書內(nèi)容是HTTP報文,寫在紙上是TCP首部,包上信封寫上郵編啊地址?。ń夬澴由夏墙猩叮浚┦荌P首部,綁上對應(yīng)的??啦送給對應(yīng)的郵差是以太網(wǎng)首部。(雖然比喻不太合適,這樣就好記多了。)
IP、TCP、DNS

#######IP
按層次分,IP(Internet Protocol)網(wǎng)際協(xié)議,屬于網(wǎng)絡(luò)層。


路由選擇機制(routing),在到達通信目標前,網(wǎng)絡(luò)設(shè)備只能知道粗略的傳輸設(shè)備。
雖然還是不明白為什么會有這樣的機制產(chǎn)生。。后續(xù)再看?
大概理由是因為封裝了多層,只有到對應(yīng)位置解開封裝之后才能知道??而且本身協(xié)議太過簡單?

#######TCP
TCP位于傳輸層,提供可靠的字節(jié)服務(wù),確??煽啃?。


##########TCP的三次握手(three-way handshaking)
三次握手可以拆分這樣三次:
1.發(fā)送端發(fā)送出帶有SYN標識的數(shù)據(jù)包給接收端
2.接收端收到并返回帶有SYN/ACK標識的數(shù)據(jù)包給發(fā)送端以傳達收到消息。
3.發(fā)送端收到后,再傳回ACK標識的數(shù)據(jù)包給接收端,表示知道送達了,握手結(jié)束。
如果握手過程中莫名中斷失敗了,發(fā)送端重啟握手順序發(fā)送數(shù)據(jù)。

說白了三次握手的方式其實就是發(fā)送端和接收端玩一個“間諜游戲”,發(fā)送端發(fā)出自己能是別的標識數(shù)據(jù),接收端收到之后將發(fā)送來的標識和自己的標識發(fā)給發(fā)送端,發(fā)送端收到接收到的消息,識別到自己的標識,說明接收端確實收到了,然后再把接收端的標識單獨發(fā)回去。兩端其實都不需要知道對方的標識是什么意思,哪怕是一個shit,不用解析反正就是反手發(fā)回去就行。(至于是不是真的不需要解析,我還不知道。
TCP不止三次握手這種可靠性手段,應(yīng)該還有其他手段,后續(xù)去了解。

#######DNS
DNS位于應(yīng)用層,用于域名到IP地址之間的解析。

各種協(xié)議各司其職
URI和URL區(qū)別?
URI是某個協(xié)議方案表示的資源定位標識符,用字符串標識某一互聯(lián)網(wǎng)資源。
URL是統(tǒng)一資源定位符,用字符串表示資源的地點。

第二章HTTP

兩臺計算機使用HTTP進行通信時,必有客戶端和服務(wù)端。發(fā)送請求為客戶端,響應(yīng)請求為服務(wù)端。

HTTP是有請求才會有響應(yīng),那么即時通信類的是怎么一個原理呢?肯定不是HTTP。socket的原理啦什么的后續(xù)去看看。

寫到這里發(fā)現(xiàn)關(guān)于HTTP的需要多看幾遍才能寫的有條理。。先放著。。再多看幾遍???♀?

最后編輯于
?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
【社區(qū)內(nèi)容提示】社區(qū)部分內(nèi)容疑似由AI輔助生成,瀏覽時請結(jié)合常識與多方信息審慎甄別。
平臺聲明:文章內(nèi)容(如有圖片或視頻亦包括在內(nèi))由作者上傳并發(fā)布,文章內(nèi)容僅代表作者本人觀點,簡書系信息發(fā)布平臺,僅提供信息存儲服務(wù)。

相關(guān)閱讀更多精彩內(nèi)容

  • 1.OkHttp源碼解析(一):OKHttp初階2 OkHttp源碼解析(二):OkHttp連接的"前戲"——HT...
    隔壁老李頭閱讀 21,572評論 24 176
  • 個人認為,Goodboy1881先生的TCP /IP 協(xié)議詳解學習博客系列博客是一部非常精彩的學習筆記,這雖然只是...
    貳零壹柒_fc10閱讀 5,192評論 0 8
  • 1.這篇文章不是本人原創(chuàng)的,只是個人為了對這部分知識做一個整理和系統(tǒng)的輸出而編輯成的,在此鄭重地向本文所引用文章的...
    SOMCENT閱讀 13,360評論 6 174
  • 協(xié)議基礎(chǔ) 協(xié)議就是計算機之間通過網(wǎng)絡(luò)實現(xiàn)通信時實現(xiàn)所達成的一種“約定”,這種約定使得那些由不同廠商的設(shè)備,不同的C...
    d9fc24a0c9a9閱讀 2,517評論 0 6
  • * 厚道 厚德載物,就是說人只要有好德行,就沒有承載不了的事,相反,人無大德便無法成就大事。要樂于吃虧,多為別人著...
    范亞坤閱讀 1,274評論 0 3

友情鏈接更多精彩內(nèi)容