1. 常見網(wǎng)絡(luò)編程面試題

        共 12049字,需瀏覽 25分鐘

         ·

        2021-05-19 06:04

        點擊“程序員面試吧”,選擇“星標(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ò)協(xié)議是什么?

        在計算機網(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)。


        TCP/IP 協(xié)議族


        應(yīng)用層

        應(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)用層報文。

        運輸層主要使用一下兩種協(xié)議:

        • 傳輸控制協(xié)議-TCP:提供面向連接的,可靠的數(shù)據(jù)傳輸服務(wù)。

        • 用戶數(shù)據(jù)協(xié)議-UDP:提供無連接的,盡最大努力的數(shù)據(jù)傳輸服務(wù)(不保證數(shù)據(jù)傳輸?shù)目煽啃裕?/p>



        UDPTCP
        是否連接無連接面向連接
        是否可靠不可靠傳輸,不使用流量控制和擁塞控制可靠傳輸,使用流量控制和擁塞控制
        連接對象個數(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),用于加密安全登陸用。


        運行在UDP協(xié)議上的協(xié)議:

        • 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地址。


        運行在TCP和UDP協(xié)議上:

        • DNS(Domain Name Service,域名服務(wù)),用于完成地址查找,郵件轉(zhuǎn)發(fā)等工作。


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

        網(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ù)鏈路層

        數(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ā)生變化,對傳送的比特流來說,這個電路好像是看不見的。

        TCP/IP 協(xié)議族

        在互聯(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的三次握手四次揮手


        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 報文的頭部結(jié)構(gòu)

        在了解 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 等,具體含義如下:

          • ACK:確認序號有效。

          • FIN:釋放一個連接。

          • PSH:接收方應(yīng)該盡快將這個報文交給應(yīng)用層。

          • RST:重置連接。

          • SYN:發(fā)起一個新連接。

          • URG:緊急指針(urgent pointer)有效。


        需要注意的是:

        • 不要將確認序號 ACK 與標(biāo)志位中的 ACK 搞混了。

        • 確認方 ack = 發(fā)起方 seq + 1,兩端配對。


        三次握手

        三次握手的本質(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 建立了連接。


        四次揮手

        四次揮手的目的是關(guān)閉一個連接。


        比如客戶端初始化的序列號 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ū)別HTTPHTTPS
        協(xié)議運行在 TCP 之上,明文傳輸,客戶端與服務(wù)器端都無法驗證對方的身份身披 SSL( Secure Socket Layer )外殼的 HTTP,運行于 SSL 上,SSL 運行于 TCP 之上, 是添加了加密和認證機制的 HTTP。
        端口80443
        資源消耗較少由于加解密處理,會消耗更多的 CPU 和內(nèi)存資源
        開銷無需證書需要證書,而證書一般需要向認證機構(gòu)購買
        加密機制共享密鑰加密和公開密鑰加密并用的混合加密機制
        安全性由于加密機制,安全性強

        常用 HTTP 狀態(tài)碼

        HTTP 狀態(tài)碼表示客戶端 HTTP 請求的返回結(jié)果、標(biāo)識服務(wù)器處理是否正常、表明請求出現(xiàn)的錯誤等。

        狀態(tài)碼的類別:


        類別原因短語
        1XXInformational(信息性狀態(tài)碼) 接受的請求正在處理
        2XXSuccess(成功狀態(tài)碼) 請求正常處理完畢
        3XXRedirection(重定向狀態(tài)碼) 需要進行附加操作以完成請求
        4XXClient Error(客戶端錯誤狀態(tài)碼) 服務(wù)器無法處理請求
        5XXServer Error(服務(wù)器錯誤狀態(tài)碼) 服務(wù)器處理請求出錯

        常用 HTTP 狀態(tài)碼:

        2XX成功(這系列表明請求被正常處理了)
        200OK,表示從客戶端發(fā)來的請求在服務(wù)器端被正確處理
        204No content,表示請求成功,但響應(yīng)報文不含實體的主體部分
        206Partial Content,進行范圍請求成功


        3XX重定向(表明瀏覽器要執(zhí)行特殊處理)
        301moved permanently,永久性重定向,表示資源已被分配了新的 URL
        302found,臨時性重定向,表示資源臨時被分配了新的 URL
        303see other,表示資源存在著另一個 URL,應(yīng)使用 GET 方法獲取資源(對于301/302/303響應(yīng),幾乎所有瀏覽器都會刪除報文主體并自動用GET重新請求)
        304not modified,表示服務(wù)器允許訪問資源,但請求未滿足條件的情況(與重定向無關(guān))
        307temporary redirect,臨時重定向,和302含義類似,但是期望客戶端保持請求方法不變向新的地址發(fā)出請求


        4XX客戶端錯誤
        400bad request,請求報文存在語法錯誤
        401unauthorized,表示發(fā)送的請求需要有通過 HTTP 認證的認證信息
        403forbidden,表示對請求資源的訪問被服務(wù)器拒絕,可在實體主體部分返回原因描述
        404not found,表示在服務(wù)器上沒有找到請求的資源


        5XX服務(wù)器錯誤
        500internal sever error,表示服務(wù)器端在執(zhí)行請求時發(fā)生了錯誤
        501Not Implemented,表示服務(wù)器不支持當(dāng)前請求所需要的某個功能
        503service unavailable,表明服務(wù)器暫時處于超負載或正在停機維護,無法處理請求


        GET 和 POST 區(qū)別

        說道 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 和 POST 區(qū)別:

        • 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ā)送用來解密的私鑰,所以可以保證安全性;但是和對稱加密比起來,非常的慢。

        什么是 HTTP2?

        HTTP2 可以提高了網(wǎng)頁的性能。

        在 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

        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

        Session 是依賴 Cookie 實現(xiàn)的。Session 是服務(wù)器端對象。

        Session 是瀏覽器和服務(wù)器會話過程中,服務(wù)器分配的一塊儲存空間。服務(wù)器默認為瀏覽器在 Cookie 中設(shè)置 sessionid,瀏覽器在向服務(wù)器請求過程中傳輸 Cookie 包含 sessionid ,服務(wù)器根據(jù) sessionid 獲取出會話中存儲的信息,然后確定會話的身份信息。

        Cookie 與 Session 區(qū)別

        • 存儲位置與安全性: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 的引入: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 與 Token 區(qū)別

        • Session 機制存在服務(wù)器壓力增大,CSRF 跨站偽造請求攻擊,擴展性不強等問題;

        • Session 存儲在服務(wù)器端,Token 存儲在客戶端

        • Token 提供認證和授權(quán)功能,作為身份認證,Token 安全性比 Session 好;

        • Session這種會話存儲方式方式只適用于客戶端代碼和服務(wù)端代碼運行在同一臺服務(wù)器上,Token 適用于項目級的前后端分離(前后端代碼運行在不同的服務(wù)器下)


        Servlet 是線程安全的嗎?

        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)途徑有以下幾種:

        • 手動通過 URL 傳值、隱藏表單傳遞 Session ID。

        • 用文件、數(shù)據(jù)庫等形式保存 Session ID,在跨頁過程中手動調(diào)用。


        原文鏈接:https://blog.csdn.net/ThinkWon/article/details/104903925





        瀏覽 40
        點贊
        評論
        收藏
        分享

        手機掃一掃分享

        分享
        舉報
        評論
        圖片
        表情
        推薦
        點贊
        評論
        收藏
        分享

        手機掃一掃分享

        分享
        舉報
          
          

            1. 日韩精品人妻在线高清不卡一区二区 | 美女黄色免费 | 操逼真爽| 老牛影视无码一区二区 | www.日本黄色 |