點擊“程序員面試吧”,選擇“星標(biāo)??”
點擊文末“閱讀原文”解鎖資料!
計算機網(wǎng)絡(luò)體系結(jié)構(gòu)
在計算機網(wǎng)絡(luò)的基本概念中,分層次的體系結(jié)構(gòu)是最基本的。計算機網(wǎng)絡(luò)體系結(jié)構(gòu)的抽象概念較多,在學(xué)習(xí)時要多思考。這些概念對后面的學(xué)習(xí)很有幫助。在計算機網(wǎng)絡(luò)要做到有條不紊地交換數(shù)據(jù),就必須遵守一些事先約定好的規(guī)則,比如交換數(shù)據(jù)的格式、是否需要發(fā)送一個應(yīng)答信息。這些規(guī)則被稱為網(wǎng)絡(luò)協(xié)議。為什么要對網(wǎng)絡(luò)協(xié)議分層?簡化問題難度和復(fù)雜度。由于各層之間獨立,我們可以分割大問題為小問題。
靈活性好。當(dāng)其中一層的技術(shù)變化時,只要層間接口關(guān)系保持不變,其他層不受影響。
易于實現(xiàn)和維護。
促進標(biāo)準(zhǔn)化工作。分開后,每層功能可以相對簡單地被描述。
網(wǎng)絡(luò)協(xié)議分層的缺點:功能可能出現(xiàn)在多個層里,產(chǎn)生了額外開銷。為了使不同體系結(jié)構(gòu)的計算機網(wǎng)絡(luò)都能互聯(lián),國際標(biāo)準(zhǔn)化組織 ISO 于 1977 年提出了一個試圖使各種計算機在世界范圍內(nèi)互聯(lián)成網(wǎng)的標(biāo)準(zhǔn)框架,即著名的開放系統(tǒng)互聯(lián)基本參考模型 OSI/RM,簡稱為 OSI。OSI 的七層協(xié)議體系結(jié)構(gòu)的概念清楚,理論也較完整,但它既復(fù)雜又不實用,TCP/IP 體系結(jié)構(gòu)則不同,但它現(xiàn)在卻得到了非常廣泛的應(yīng)用。TCP/IP 是一個四層體系結(jié)構(gòu),它包含應(yīng)用層,運輸層,網(wǎng)際層和網(wǎng)絡(luò)接口層(用網(wǎng)際層這個名字是強調(diào)這一層是為了解決不同網(wǎng)絡(luò)的互連問題),不過從實質(zhì)上講,TCP/IP 只有最上面的三層,因為最下面的網(wǎng)絡(luò)接口層并沒有什么具體內(nèi)容,因此在學(xué)習(xí)計算機網(wǎng)絡(luò)的原理時往往采用折中的辦法,即綜合 OSI 和 TCP/IP 的優(yōu)點,采用一種只有五層協(xié)議的體系結(jié)構(gòu),這樣既簡潔又能將概念闡述清楚,有時為了方便,也可把最底下兩層稱為網(wǎng)絡(luò)接口層。四層協(xié)議,五層協(xié)議和七層協(xié)議的關(guān)系如下:TCP/IP是一個四層的體系結(jié)構(gòu),主要包括:應(yīng)用層、運輸層、網(wǎng)際層和網(wǎng)絡(luò)接口層。
五層協(xié)議的體系結(jié)構(gòu)主要包括:應(yīng)用層、運輸層、網(wǎng)絡(luò)層,數(shù)據(jù)鏈路層和物理層。
OSI七層協(xié)議模型主要包括是:應(yīng)用層(Application)、表示層(Presentation)、會話層(Session)、運輸層(Transport)、網(wǎng)絡(luò)層(Network)、數(shù)據(jù)鏈路層(Data Link)、物理層(Physical)。
注:五層協(xié)議的體系結(jié)構(gòu)只是為了介紹網(wǎng)絡(luò)原理而設(shè)計的,實際應(yīng)用還是 TCP/IP 四層體系結(jié)構(gòu)。

應(yīng)用層(application-layer)的任務(wù)是通過應(yīng)用進程間的交互來完成特定網(wǎng)絡(luò)應(yīng)用。應(yīng)用層協(xié)議定義的是應(yīng)用進程(進程:主機中正在運行的程序)間的通信和交互的規(guī)則。對于不同的網(wǎng)絡(luò)應(yīng)用需要不同的應(yīng)用層協(xié)議。在互聯(lián)網(wǎng)中應(yīng)用層協(xié)議很多,如域名系統(tǒng) DNS,支持萬維網(wǎng)應(yīng)用的 HTTP 協(xié)議,支持電子郵件的 SMTP 協(xié)議等等。運輸層(transport layer)的主要任務(wù)就是負責(zé)向兩臺主機進程之間的通信提供通用的數(shù)據(jù)傳輸服務(wù)。應(yīng)用進程利用該服務(wù)傳送應(yīng)用層報文。
| UDP | TCP |
| 是否連接 | 無連接 | 面向連接 |
| 是否可靠 | 不可靠傳輸,不使用流量控制和擁塞控制 | 可靠傳輸,使用流量控制和擁塞控制 |
| 連接對象個數(shù) | 支持一對一,一對多,多對一和多對多交互通信 | 只能是一對一通信 |
| 傳輸方式 | 面向報文 | 面向字節(jié)流 |
| 首部開銷 | 首部開銷小,僅8字節(jié) | 首部最小20字節(jié),最大60字節(jié) |
| 場景 | 適用于實時應(yīng)用(IP電話、視頻會議、直播等) | 適用于要求可靠傳輸?shù)膽?yīng)用,例如文件傳輸 |
每一個應(yīng)用層(TCP/IP 參考模型的最高層)協(xié)議一般都會使用到兩個傳輸層協(xié)議之一。運行在 TCP 協(xié)議上的協(xié)議:HTTP(Hypertext Transfer Protocol,超文本傳輸協(xié)議),主要用于普通瀏覽。
HTTPS(HTTP over SSL,安全超文本傳輸協(xié)議),HTTP 協(xié)議的安全版本。
FTP(File Transfer Protocol,文件傳輸協(xié)議),用于文件傳輸。
POP3(Post Office Protocol,version 3,郵局協(xié)議),收郵件用。
SMTP(Simple Mail Transfer Protocol,簡單郵件傳輸協(xié)議),用來發(fā)送電子郵件。
TELNET(Teletype over the Network,網(wǎng)絡(luò)電傳),通過一個終端(terminal)登陸到網(wǎng)絡(luò)。
SSH(Secure Shell,用于替代安全性差的 TELNET),用于加密安全登陸用。
BOOTP(Boot Protocol,啟動協(xié)議),應(yīng)用于無盤設(shè)備。
NTP(Network Time Protocol,網(wǎng)絡(luò)時間協(xié)議),用于網(wǎng)絡(luò)同步。
DHCP(Dynamic Host Configuration Protocol,動態(tài)主機配置協(xié)議),動態(tài)配置IP地址。
網(wǎng)絡(luò)層的任務(wù)就是選擇合適的網(wǎng)間路由和交換結(jié)點,確保計算機通信的數(shù)據(jù)及時傳送。在發(fā)送數(shù)據(jù)時,網(wǎng)絡(luò)層把運輸層產(chǎn)生的報文段或用戶數(shù)據(jù)報封裝成分組和包進行傳送。在 TCP/IP 體系結(jié)構(gòu)中,由于網(wǎng)絡(luò)層使用 IP 協(xié)議,因此分組也叫 IP 數(shù)據(jù)報 ,簡稱數(shù)據(jù)報。互聯(lián)網(wǎng)是由大量的異構(gòu)(heterogeneous)網(wǎng)絡(luò)通過路由器(router)相互連接起來的?;ヂ?lián)網(wǎng)使用的網(wǎng)絡(luò)層協(xié)議是無連接的網(wǎng)際協(xié)議(Intert Prococol)和許多路由選擇協(xié)議,因此互聯(lián)網(wǎng)的網(wǎng)絡(luò)層也叫做網(wǎng)際層或 IP 層。數(shù)據(jù)鏈路層(data link layer)通常簡稱為鏈路層。兩臺主機之間的數(shù)據(jù)傳輸,總是在一段一段的鏈路上傳送的,這就需要使用專門的鏈路層的協(xié)議。在兩個相鄰節(jié)點之間傳送數(shù)據(jù)時,數(shù)據(jù)鏈路層將網(wǎng)絡(luò)層交下來的 IP 數(shù)據(jù)報組裝成幀,在兩個相鄰節(jié)點間的鏈路上傳送幀。每一幀包括數(shù)據(jù)和必要的控制信息(如同步信息,地址信息,差錯控制等)。在接收數(shù)據(jù)時,控制信息使接收端能夠知道一個幀從哪個比特開始和到哪個比特結(jié)束。一般的Web應(yīng)用的通信傳輸流是這樣的:發(fā)送端在層與層之間傳輸數(shù)據(jù)時,每經(jīng)過一層時會被打上一個該層所屬的首部信息。反之,接收端在層與層之間傳輸數(shù)據(jù)時,每經(jīng)過一層時會把對應(yīng)的首部信息去除。在物理層上所傳送的數(shù)據(jù)單位是比特。物理層(physical layer)的作用是實現(xiàn)相鄰計算機節(jié)點之間比特流的透明傳送,盡可能屏蔽掉具體傳輸介質(zhì)和物理設(shè)備的差異。使其上面的數(shù)據(jù)鏈路層不必考慮網(wǎng)絡(luò)的具體傳輸介質(zhì)是什么?!巴该鱾魉捅忍亓鳌北硎窘?jīng)實際電路傳送后的比特流沒有發(fā)生變化,對傳送的比特流來說,這個電路好像是看不見的。在互聯(lián)網(wǎng)使用的各種協(xié)議中最重要和最著名的就是 TCP/IP 兩個協(xié)議?,F(xiàn)在人們經(jīng)常提到的 TCP/IP 并不一定是單指 TCP 和 IP 這兩個具體的協(xié)議,而往往是表示互聯(lián)網(wǎng)所使用的整個 TCP/IP 協(xié)議族。互聯(lián)網(wǎng)協(xié)議套件(英語:Internet Protocol Suite,縮寫IPS)是一個網(wǎng)絡(luò)通訊模型,以及一整個網(wǎng)絡(luò)傳輸協(xié)議家族,為網(wǎng)際網(wǎng)絡(luò)的基礎(chǔ)通訊架構(gòu)。它常被通稱為 TCP/IP 協(xié)議族(英語:TCP/IP Protocol Suite,或 TCP/IP Protocols),簡稱 TCP/IP。因為該協(xié)定家族的兩個核心協(xié)定:TCP(傳輸控制協(xié)議)和IP(網(wǎng)際協(xié)議),為該家族中最早通過的標(biāo)準(zhǔn)。劃重點:TCP(傳輸控制協(xié)議)和 IP(網(wǎng)際協(xié)議) 是最先定義的兩個核心協(xié)議,所以才統(tǒng)稱為 TCP/IP 協(xié)議族。

TCP 是一種面向連接的、可靠的、基于字節(jié)流的傳輸層通信協(xié)議,在發(fā)送數(shù)據(jù)前,通信雙方必須在彼此間建立一條連接。所謂的“連接”,其實是客戶端和服務(wù)端保存的一份關(guān)于對方的信息,如 IP 地址、端口號等。TCP 可以看成是一種字節(jié)流,它會處理 IP 層或以下的層的丟包、重復(fù)以及錯誤問題。在連接的建立過程中,雙方需要交換一些連接的參數(shù)。這些參數(shù)可以放在 TCP 頭部。一個 TCP 連接由一個 4 元組構(gòu)成,分別是兩個 IP 地址和兩個端口號。一個 TCP 連接通常分為三個階段:連接、數(shù)據(jù)傳輸、退出(關(guān)閉)。通過三次握手建立一個鏈接,通過四次揮手來關(guān)閉一個連接。當(dāng)一個連接被建立或被終止時,交換的報文段只包含 TCP 頭部,而沒有數(shù)據(jù)。在了解 TCP 連接之前先來了解一下 TCP 報文的頭部結(jié)構(gòu)。序號:seq 序號,占 32 位,用來標(biāo)識從 TCP 源端向目的端發(fā)送的字節(jié)流,發(fā)起方發(fā)送數(shù)據(jù)時對此進行標(biāo)記。
確認序號:ACK 序號,占 32 位,只有 ACK 標(biāo)志位為1時,確認序號字段才有效,ack=seq+1。
標(biāo)志位:共 6 個,即 URG、ACK、PSH、RST、SYN、FIN 等,具體含義如下:
三次握手的本質(zhì)是確認通信雙方收發(fā)數(shù)據(jù)的能力。首先,我讓信使運輸一份信件給對方,對方收到了,那么他就知道了我的發(fā)件能力和他的收件能力是可以的。于是他給我回信,我若收到了,我便知我的發(fā)件能力和他的收件能力是可以的,并且他的發(fā)件能力和我的收件能力是可以。然而此時他還不知道他的發(fā)件能力和我的收件能力到底可不可以,于是我最后回饋一次,他若收到了,他便清楚了他的發(fā)件能力和我的收件能力是可以的。第一次握手:客戶端要向服務(wù)端發(fā)起連接請求,首先客戶端隨機生成一個起始序列號 ISN(比如是 100),那客戶端向服務(wù)端發(fā)送的報文段包含 SYN 標(biāo)志位(也就是 SYN = 1),序列號 seq = 100。
第二次握手:服務(wù)端收到客戶端發(fā)過來的報文后,發(fā)現(xiàn) SYN = 1,知道這是一個連接請求,于是將客戶端的起始序列號 100 存起來,并且隨機生成一個服務(wù)端的起始序列號(比如是 300)。然后給客戶端回復(fù)一段報文,回復(fù)報文包含 SYN 和 ACK 標(biāo)志(也就是 SYN = 1,ACK = 1)、序列號 seq = 300、確認號 ack = 101(客戶端發(fā)過來的序列號 + 1)。
第三次握手:客戶端收到服務(wù)端的回復(fù)后發(fā)現(xiàn) ACK = 1并且 ack =101,于是知道服務(wù)端已經(jīng)收到了序列號為 100 的那段報文;同時發(fā)現(xiàn) SYN = 1,知道了服務(wù)端同意了這次連接,于是就將服務(wù)端的序列號 300 給存下來。然后客戶端再回復(fù)一段報文給服務(wù)端,報文包含 ACK 標(biāo)志位(ACK = 1)、ack = 301(服務(wù)端序列號+1)、seq = 101(第一次握手時發(fā)送報文是占據(jù)一個序列號的,所以這次 seq 就從 101 開始,需要注意的是不攜帶數(shù)據(jù)的 ACK 報文是不占據(jù)序列號的,所以后面第一次正式發(fā)送數(shù)據(jù)時 seq 還是 101)。當(dāng)服務(wù)端收到報文后發(fā)現(xiàn) ACK = 1 并且 ack = 301,就知道客戶端收到序列號為 300 的報文了,就這樣客戶端和服務(wù)端通過 TCP 建立了連接。
比如客戶端初始化的序列號 ISA = 100,服務(wù)端初始化的序列號 ISA = 300。TCP 連接成功后客戶端總共發(fā)送了 1000 個字節(jié)的數(shù)據(jù),服務(wù)端在客戶端發(fā) FIN 報文前總共回復(fù)了 2000 個字節(jié)的數(shù)據(jù)。第一次揮手:當(dāng)客戶端的數(shù)據(jù)都傳輸完成后,客戶端向服務(wù)端發(fā)出連接釋放報文(當(dāng)然數(shù)據(jù)沒發(fā)完時也可以發(fā)送連接釋放報文并停止發(fā)送數(shù)據(jù)),釋放連接報文包含 FIN 標(biāo)志位(FIN = 1)、序列號 seq = 1101(100 + 1 + 1000,其中的 1 是建立連接時占的一個序列號)。需要注意的是客戶端發(fā)出 FIN 報文段后只是不能發(fā)數(shù)據(jù)了,但是還可以正常收數(shù)據(jù);另外FIN報文段即使不攜帶數(shù)據(jù)也要占據(jù)一個序列號。
第二次揮手:服務(wù)端收到客戶端發(fā)的FIN報文后給客戶端回復(fù)確認報文,確認報文包含 ACK 標(biāo)志位(ACK = 1)、確認號 ack = 1102(客戶端 FIN 報文序列號 1101 + 1)、序列號 seq = 2300(300 + 2000)。此時服務(wù)端處于關(guān)閉等待狀態(tài),而不是立馬給客戶端發(fā) FIN 報文,這個狀態(tài)還要持續(xù)一段時間,因為服務(wù)端可能還有數(shù)據(jù)沒發(fā)完。
第三次揮手:服務(wù)端將最后數(shù)據(jù)(比如 50 個字節(jié))發(fā)送完畢后就向客戶端發(fā)出連接釋放報文,報文包含 FIN 和 ACK 標(biāo)志位(FIN = 1,ACK = 1)、確認號和第二次揮手一樣 ack = 1102、序列號 seq = 2350(2300 + 50)。
第四次揮手:客戶端收到服務(wù)端發(fā)的FIN報文后,向服務(wù)端發(fā)出確認報文,確認報文包含 ACK 標(biāo)志位(ACK = 1)、確認號 ack = 2351、序列號 seq = 1102。注意客戶端發(fā)出確認報文后不是立馬釋放 TCP 連接,而是要經(jīng)過 2MSL(最長報文段壽命的 2 倍時長)后才釋放 TCP 連接。而服務(wù)端一旦收到客戶端發(fā)出的確認報文就會立馬釋放 TCP 連接,所以服務(wù)端結(jié)束 TCP 連接的時間要比客戶端早一些。

為什么 TCP 連接的時候是 3 次?2 次不可以嗎?因為需要考慮連接時丟包的問題,如果只握手 2 次,第二次握手時如果服務(wù)端發(fā)給客戶端的確認報文段丟失,此時服務(wù)端已經(jīng)準(zhǔn)備好了收發(fā)數(shù)據(jù)(可以理解服務(wù)端已經(jīng)連接成功),而客戶端一直沒收到服務(wù)端的確認報文,所以客戶端就不知道服務(wù)端是否已經(jīng)準(zhǔn)備好了(可以理解為客戶端未連接成功),這種情況下客戶端不會給服務(wù)端發(fā)數(shù)據(jù),也會忽略服務(wù)端發(fā)過來的數(shù)據(jù)。如果是三次握手,即便發(fā)生丟包也不會有問題,比如如果第三次握手客戶端發(fā)的確認 ack 報文丟失,服務(wù)端在一段時間內(nèi)沒有收到確認 ack 報文的話就會重新進行第二次握手,也就是服務(wù)端會重發(fā) SYN 報文段,客戶端收到重發(fā)的報文段后會再次給服務(wù)端發(fā)送確認 ack 報文。為什么 TCP 連接的時候是 3 次,關(guān)閉的時候卻是 4 次?因為只有在客戶端和服務(wù)端都沒有數(shù)據(jù)要發(fā)送的時候才能斷開 TCP。而客戶端發(fā)出 FIN 報文時只能保證客戶端沒有數(shù)據(jù)發(fā)了,服務(wù)端還有沒有數(shù)據(jù)發(fā)客戶端是不知道的。而服務(wù)端收到客戶端的 FIN 報文后只能先回復(fù)客戶端一個確認報文來告訴客戶端我服務(wù)端已經(jīng)收到你的 FIN 報文了,但我服務(wù)端還有一些數(shù)據(jù)沒發(fā)完,等這些數(shù)據(jù)發(fā)完了服務(wù)端才能給客戶端發(fā) FIN 報文(所以不能一次性將確認報文和 FIN 報文發(fā)給客戶端,就是這里多出來了一次)。為什么客戶端發(fā)出第四次揮手的確認報文后要等 2MSL 的時間才能釋放 TCP 連接?這里同樣是要考慮丟包的問題,如果第四次揮手的報文丟失,服務(wù)端沒收到確認 ack 報文就會重發(fā)第三次揮手的報文,這樣報文一去一回最長時間就是 2MSL,所以需要等這么長時間來確認服務(wù)端確實已經(jīng)收到了。如果已經(jīng)建立了連接,但是客戶端突然出現(xiàn)故障了怎么辦?TCP 設(shè)有一個保活計時器,客戶端如果出現(xiàn)故障,服務(wù)器不能一直等下去,白白浪費資源。服務(wù)器每收到一次客戶端的請求后都會重新復(fù)位這個計時器,時間通常是設(shè)置為 2 小時,若兩小時還沒有收到客戶端的任何數(shù)據(jù),服務(wù)器就會發(fā)送一個探測報文段,以后每隔 75 秒鐘發(fā)送一次。若一連發(fā)送 10 個探測報文仍然沒反應(yīng),服務(wù)器就認為客戶端出了故障,接著就關(guān)閉連接。什么是 HTTP,HTTP 與 HTTPS 有什么區(qū)別?HTTP 是一個在計算機世界里專門在兩點之間傳輸文字、圖片、音頻、視頻等超文本數(shù)據(jù)的約定和規(guī)范。
| 區(qū)別 | HTTP | HTTPS |
| 協(xié)議 | 運行在 TCP 之上,明文傳輸,客戶端與服務(wù)器端都無法驗證對方的身份 | 身披 SSL( Secure Socket Layer )外殼的 HTTP,運行于 SSL 上,SSL 運行于 TCP 之上, 是添加了加密和認證機制的 HTTP。 |
| 端口 | 80 | 443 |
| 資源消耗 | 較少 | 由于加解密處理,會消耗更多的 CPU 和內(nèi)存資源 |
| 開銷 | 無需證書 | 需要證書,而證書一般需要向認證機構(gòu)購買 |
| 加密機制 | 無 | 共享密鑰加密和公開密鑰加密并用的混合加密機制 |
| 安全性 | 弱 | 由于加密機制,安全性強 |
HTTP 狀態(tài)碼表示客戶端 HTTP 請求的返回結(jié)果、標(biāo)識服務(wù)器處理是否正常、表明請求出現(xiàn)的錯誤等。
| 類別 | 原因短語 |
| 1XX | Informational(信息性狀態(tài)碼) 接受的請求正在處理 |
| 2XX | Success(成功狀態(tài)碼) 請求正常處理完畢 |
| 3XX | Redirection(重定向狀態(tài)碼) 需要進行附加操作以完成請求 |
| 4XX | Client Error(客戶端錯誤狀態(tài)碼) 服務(wù)器無法處理請求 |
| 5XX | Server Error(服務(wù)器錯誤狀態(tài)碼) 服務(wù)器處理請求出錯 |
| 2XX | 成功(這系列表明請求被正常處理了) |
| 200 | OK,表示從客戶端發(fā)來的請求在服務(wù)器端被正確處理 |
| 204 | No content,表示請求成功,但響應(yīng)報文不含實體的主體部分 |
| 206 | Partial Content,進行范圍請求成功 |
| 3XX | 重定向(表明瀏覽器要執(zhí)行特殊處理) |
| 301 | moved permanently,永久性重定向,表示資源已被分配了新的 URL |
| 302 | found,臨時性重定向,表示資源臨時被分配了新的 URL |
| 303 | see other,表示資源存在著另一個 URL,應(yīng)使用 GET 方法獲取資源(對于301/302/303響應(yīng),幾乎所有瀏覽器都會刪除報文主體并自動用GET重新請求) |
| 304 | not modified,表示服務(wù)器允許訪問資源,但請求未滿足條件的情況(與重定向無關(guān)) |
| 307 | temporary redirect,臨時重定向,和302含義類似,但是期望客戶端保持請求方法不變向新的地址發(fā)出請求 |
| 4XX | 客戶端錯誤 |
| 400 | bad request,請求報文存在語法錯誤 |
| 401 | unauthorized,表示發(fā)送的請求需要有通過 HTTP 認證的認證信息 |
| 403 | forbidden,表示對請求資源的訪問被服務(wù)器拒絕,可在實體主體部分返回原因描述 |
| 404 | not found,表示在服務(wù)器上沒有找到請求的資源 |
| 5XX | 服務(wù)器錯誤 |
| 500 | internal sever error,表示服務(wù)器端在執(zhí)行請求時發(fā)生了錯誤 |
| 501 | Not Implemented,表示服務(wù)器不支持當(dāng)前請求所需要的某個功能 |
| 503 | service unavailable,表明服務(wù)器暫時處于超負載或正在停機維護,無法處理請求 |
說道 GET 和 POST,就不得不提 HTTP 協(xié)議,因為瀏覽器和服務(wù)器的交互是通過 HTTP 協(xié)議執(zhí)行的,而 GET 和 POST 也是 HTTP 協(xié)議中的兩種方法。HTTP 全稱為 Hyper Text Transfer Protocol,中文翻譯為超文本傳輸協(xié)議,目的是保證瀏覽器與服務(wù)器之間的通信。HTTP的工作方式是客戶端與服務(wù)器之間的請求-應(yīng)答協(xié)議。HTTP 協(xié)議中定義了瀏覽器和服務(wù)器進行交互的不同方法,基本方法有 4 種,分別是 GET,POST,PUT,DELETE。這四種方法可以理解為,對服務(wù)器資源的查,改,增,刪。GET:從服務(wù)器上獲取數(shù)據(jù),也就是所謂的查,僅僅是獲取服務(wù)器資源,不進行修改。
POST:向服務(wù)器提交數(shù)據(jù),這就涉及到了數(shù)據(jù)的更新,也就是更改服務(wù)器的數(shù)據(jù)。
PUT:英文含義是放置,也就是向服務(wù)器新添加數(shù)據(jù),就是所謂的增。
DELETE:從字面意思也能看出,這種方式就是刪除服務(wù)器數(shù)據(jù)的過程。
Get 是不安全的,因為在傳輸過程,數(shù)據(jù)被放在請求的 URL 中;Post 的所有操作對用戶來說都是不可見的。但是這種做法也不時絕對的,大部分人的做法也是按照上面的說法來的,但是也可以在 get 請求加上 request body,給 post 請求帶上 URL 參數(shù)。
Get 請求提交的 url 中的數(shù)據(jù)最多只能是 2048 字節(jié),這個限制是瀏覽器或者服務(wù)器給添加的,http 協(xié)議并沒有對 url 長度進行限制,目的是為了保證服務(wù)器和瀏覽器能夠正常運行,防止有人惡意發(fā)送請求。Post 請求則沒有大小限制。
Get 限制 Form 表單的數(shù)據(jù)集的值必須為 ASCII 字符;而 Post 支持整個 ISO10646字符集。
Get 執(zhí)行效率卻比 Post 方法好。Get 是 form 提交的默認方法。
GET 產(chǎn)生一個 TCP 數(shù)據(jù)包;POST 產(chǎn)生兩個 TCP 數(shù)據(jù)包。
對于 GET 方式的請求,瀏覽器會把 http header 和 data 一并發(fā)送出去,服務(wù)器響應(yīng) 200(返回數(shù)據(jù));而對于 POST,瀏覽器先發(fā)送 header,服務(wù)器響應(yīng) 100 continue,瀏覽器再發(fā)送 data,服務(wù)器響應(yīng) 200 ok(返回數(shù)據(jù))。
對稱密鑰加密是指加密和解密使用同一個密鑰的方式,這種方式存在的最大問題就是密鑰發(fā)送問題,即如何安全地將密鑰發(fā)給對方。而非對稱加密是指使用一對非對稱密鑰,即公鑰和私鑰,公鑰可以隨意發(fā)布,但私鑰只有自己知道。發(fā)送密文的一方使用對方的公鑰進行加密處理,對方接收到加密信息后,使用自己的私鑰進行解密。由于非對稱加密的方式不需要發(fā)送用來解密的私鑰,所以可以保證安全性;但是和對稱加密比起來,非常的慢。在 HTTP1 中瀏覽器限制了同一個域名下的請求數(shù)量(Chrome 下一般是六個),當(dāng)在請求很多資源的時候,由于隊頭阻塞當(dāng)瀏覽器達到最大請求數(shù)量時,剩余的資源需等待當(dāng)前的六個請求完成后才能發(fā)起請求。HTTP2 中引入了多路復(fù)用的技術(shù),這個技術(shù)可以只通過一個 TCP 連接就可以傳輸所有的請求數(shù)據(jù)。多路復(fù)用可以繞過瀏覽器限制同一個域名下的請求數(shù)量的問題,進而提高了網(wǎng)頁的性能。Session、Cookie 和 Token 的主要區(qū)別HTTP 協(xié)議本身是無狀態(tài)的。什么是無狀態(tài)呢,即服務(wù)器無法判斷用戶身份。Cookie 是由 Web 服務(wù)器保存在用戶瀏覽器上的小文件(key-value 格式),包含用戶相關(guān)的信息??蛻舳讼蚍?wù)器發(fā)起請求,如果服務(wù)器需要記錄該用戶狀態(tài),就使用 response 向客戶端瀏覽器頒發(fā)一個 Cookie。客戶端瀏覽器會把 Cookie 保存起來。當(dāng)瀏覽器再請求該網(wǎng)站時,瀏覽器把請求的網(wǎng)址連同該 Cookie 一同提交給服務(wù)器。服務(wù)器檢查該 Cookie,以此來辨認用戶身份。Session 是依賴 Cookie 實現(xiàn)的。Session 是服務(wù)器端對象。Session 是瀏覽器和服務(wù)器會話過程中,服務(wù)器分配的一塊儲存空間。服務(wù)器默認為瀏覽器在 Cookie 中設(shè)置 sessionid,瀏覽器在向服務(wù)器請求過程中傳輸 Cookie 包含 sessionid ,服務(wù)器根據(jù) sessionid 獲取出會話中存儲的信息,然后確定會話的身份信息。存儲位置與安全性:Cookie 數(shù)據(jù)存放在客戶端上,安全性較差,Session 數(shù)據(jù)放在服務(wù)器上,安全性相對更高;
存儲空間:單個 Cookie 保存的數(shù)據(jù)不能超過4 K,很多瀏覽器都限制一個站點最多保存 20 個 Cookie,Session 無此限制
占用服務(wù)器資源:Session 一定時間內(nèi)保存在服務(wù)器上,當(dāng)訪問增多,占用服務(wù)器性能,考慮到服務(wù)器性能方面,應(yīng)當(dāng)使用 Cookie。
Token 的引入:Token 是在客戶端頻繁向服務(wù)端請求數(shù)據(jù),服務(wù)端頻繁的去數(shù)據(jù)庫查詢用戶名和密碼并進行對比,判斷用戶名和密碼正確與否,并作出相應(yīng)提示,在這樣的背景下,Token 便應(yīng)運而生。Token 的定義:Token 是服務(wù)端生成的一串字符串,以作客戶端進行請求的一個令牌,當(dāng)?shù)谝淮蔚卿浐?,服?wù)器生成一個 Token 便將此 Token 返回給客戶端,以后客戶端只需帶上這個 Token 前來請求數(shù)據(jù)即可,無需再次帶上用戶名和密碼。使用 Token 的目的:Token 的目的是為了減輕服務(wù)器的壓力,減少頻繁的查詢數(shù)據(jù)庫,使服務(wù)器更加健壯。Token 是在服務(wù)端產(chǎn)生的。如果前端使用用戶名/密碼向服務(wù)端請求認證,服務(wù)端認證成功,那么在服務(wù)端會返回 Token 給前端。前端可以在每次請求的時候帶上 Token 證明自己的合法地位。Session 機制存在服務(wù)器壓力增大,CSRF 跨站偽造請求攻擊,擴展性不強等問題;
Session 存儲在服務(wù)器端,Token 存儲在客戶端
Token 提供認證和授權(quán)功能,作為身份認證,Token 安全性比 Session 好;
Session這種會話存儲方式方式只適用于客戶端代碼和服務(wù)端代碼運行在同一臺服務(wù)器上,Token 適用于項目級的前后端分離(前后端代碼運行在不同的服務(wù)器下)
Servlet 不是線程安全的,多線程并發(fā)的讀寫會導(dǎo)致數(shù)據(jù)不同步的問題。解決的辦法是盡量不要定義 name 屬性,而是要把 name 變量分別定義在 doGet() 和 doPost() 方法內(nèi)。雖然使用 synchronized(name){} 語句塊可以解決問題,但是會造成線程的等待,不是很科學(xué)的辦法。注意:多線程的并發(fā)的讀寫 Servlet 類屬性會導(dǎo)致數(shù)據(jù)不同步。但是如果只是并發(fā)地讀取屬性而不寫入,則不存在數(shù)據(jù)不同步的問題。因此 Servlet 里的只讀屬性最好定義為 final 類型的。Servlet 接口中有哪些方法及 Servlet 生命周期探秘在 Java Web 程序中,Servlet 主要負責(zé)接收用戶請求 HttpServletRequest,在 doGet(),doPost() 中做相應(yīng)的處理,并將回應(yīng) HttpServletResponse 反饋給用戶。Servlet 可以設(shè)置初始化參數(shù),供 Servlet 內(nèi)部使用。Servlet 接口定義了 5 個方法,其中前三個方法與 Servlet 生命周期相關(guān):void init(ServletConfig config) throws ServletException
void service(ServletRequest req, ServletResponse resp) throws ServletException, java.io.IOException
void destory()
java.lang.String getServletInfo()
ServletConfig getServletConfig()
Web 容器加載 Servlet 并將其實例化后,Servlet 生命周期開始,容器運行其 init() 方法進行 Servlet 的初始化;請求到達時調(diào)用 Servlet 的 service() 方法,service() 方法會根據(jù)需要調(diào)用與請求對應(yīng)的 doGet 或 doPost 等方法;當(dāng)服務(wù)器關(guān)閉或項目被卸載時服務(wù)器會將 Servlet 實例銷毀,此時會調(diào)用 Servlet 的 destroy() 方法。init 方法和 destory 方法只會執(zhí)行一次,service 方法客戶端每次請求 Servlet 都會執(zhí)行。Servlet 中有時會用到一些需要初始化與銷毀的資源,因此可以把初始化資源的代碼放入 init 方法中,銷毀資源的代碼放入 destroy 方法中,這樣就不需要每次處理客戶端的請求都要初始化與銷毀資源。如果客戶端禁止 Cookie 能實現(xiàn) Session 還能用嗎?Cookie 與 Session,一般認為是兩個獨立的東西,Session 采用的是在服務(wù)器端保持狀態(tài)的方案,而 Cookie 采用的是在客戶端保持狀態(tài)的方案。但為什么禁用 Cookie 就不能得到 Session 呢?因為 Session 是用 Session ID 來確定當(dāng)前對話所對應(yīng)的服務(wù)器 Session,而 Session ID 是通過 Cookie 來傳遞的,禁用 Cookie 相當(dāng)于失去了 Session ID,也就得不到 Session 了。假定用戶關(guān)閉 Cookie 的情況下使用 Session,其實現(xiàn)途徑有以下幾種:
原文鏈接:https://blog.csdn.net/ThinkWon/article/details/104903925
