● 請(qǐng)問TCP三次握手是怎樣的？

參考回答：

1.客戶端發(fā)送syn0給服務(wù)器

2.服務(wù)器收到syn0，回復(fù)syn1,ack(syn0+1)
3.客戶端收到syn1，回復(fù)ack(syn1+1)

---

● 請(qǐng)問tcp握手為什么兩次不可以？為什么不用四次？

參考回答：

兩次不可以：tcp是全雙工通信，兩次握手只能確定單向數(shù)據(jù)鏈路是可以通信的，并不能保證反向的通信正常

不用四次：
本來握手應(yīng)該和揮手一樣都是需要確認(rèn)兩個(gè)方向都能聯(lián)通的，本來模型應(yīng)該是：
1.客戶端發(fā)送syn0給服務(wù)器
2.服務(wù)器收到syn0，回復(fù)ack(syn0+1)
3.服務(wù)器發(fā)送syn1
4.客戶端收到syn1，回復(fù)ack(syn1+1)
因?yàn)閠cp是全雙工的，上邊的四部確認(rèn)了數(shù)據(jù)在兩個(gè)方向上都是可以正確到達(dá)的，但是2，3步?jīng)]有沒有上下的聯(lián)系，可以將其合并，加快握手效率，所有就變成了3步握手。

---

● 請(qǐng)你來說一下TCP擁塞控制？

參考回答：

發(fā)送方維持一個(gè)叫做擁塞窗口cwnd(congestion window)的狀態(tài)變量。擁塞窗口的大小取決于網(wǎng)絡(luò)的擁塞程度，并且動(dòng)態(tài)地在變化。發(fā)送方讓自己的發(fā)送窗口等于擁塞窗口，另外考慮到接受方的接收能力，發(fā)送窗口可能小于擁塞窗口。慢開始算法的思路就是，不要一開始就發(fā)送大量的數(shù)據(jù)，先探測(cè)一下網(wǎng)絡(luò)的擁塞程度，也就是說由小到大逐漸增加擁塞窗口的大小。

過程cwnd的大小呈指數(shù)增長，直到超過慢啟動(dòng)門限，然后進(jìn)入擁塞避免階段，cwnd的大小線性增長，當(dāng)出現(xiàn)網(wǎng)絡(luò)擁塞(三個(gè)重復(fù)的ack或者超時(shí))時(shí)候，將慢啟動(dòng)門限設(shè)置為出現(xiàn)擁塞時(shí)候大小的一半，cwnd的大小重新從0開始進(jìn)入慢啟動(dòng)階段。
快重傳和快恢復(fù)：快重傳要求接收方在收到一個(gè)失序的報(bào)文段后就立即發(fā)出重復(fù)確認(rèn)(為的是使發(fā)送方及早知道有報(bào)文段沒有到達(dá)對(duì)方)而不要等到自己發(fā)送數(shù)據(jù)時(shí)捎帶確認(rèn)。快重傳算法規(guī)定，發(fā)送方只要一連收到三個(gè)重復(fù)確認(rèn)就應(yīng)當(dāng)立即重傳對(duì)方尚未收到的報(bào)文段，而不必繼續(xù)等待設(shè)置的重傳計(jì)時(shí)器時(shí)間到期

---

● TCP和UDP的區(qū)別和各自適用的場景

參考回答：

1)TCP和UDP區(qū)別

1) 連接

TCP是面向連接的傳輸層協(xié)議，即傳輸數(shù)據(jù)之前必須先建立好連接。

UDP無連接。

2) 服務(wù)對(duì)象

TCP是點(diǎn)對(duì)點(diǎn)的兩點(diǎn)間服務(wù)，即一條TCP連接只能有兩個(gè)端點(diǎn)；

UDP支持一對(duì)一，一對(duì)多，多對(duì)一，多對(duì)多的交互通信。

3) 可靠性

TCP是可靠交付：無差錯(cuò)，不丟失，不重復(fù)，按序到達(dá)。

UDP是盡最大努力交付，不保證可靠交付。

4)擁塞控制，流量控制

TCP有擁塞控制和流量控制保證數(shù)據(jù)傳輸?shù)陌踩浴?/p>

UDP沒有擁塞控制，網(wǎng)絡(luò)擁塞不會(huì)影響源主機(jī)的發(fā)送效率。

5) 報(bào)文長度

TCP是動(dòng)態(tài)報(bào)文長度，即TCP報(bào)文長度是根據(jù)接收方的窗口大小和當(dāng)前網(wǎng)絡(luò)擁塞情況決定的。

UDP面向報(bào)文，不合并，不拆分，保留上面?zhèn)飨聛韴?bào)文的邊界。

6) 首部開銷

TCP首部開銷大，首部20個(gè)字節(jié)。

UDP首部開銷小，8字節(jié)。(源端口，目的端口，數(shù)據(jù)長度，校驗(yàn)和)

2)TCP和UDP適用場景

從特點(diǎn)上我們已經(jīng)知道，TCP 是可靠的但傳輸速度慢，UDP 是不可靠的但傳輸速度快。因此在選用具體協(xié)議通信時(shí)，應(yīng)該根據(jù)通信數(shù)據(jù)的要求而決定。

若通信數(shù)據(jù)完整性需讓位與通信實(shí)時(shí)性，則應(yīng)該選用TCP 協(xié)議(如文件傳輸、重要狀態(tài)的更新等)；反之，則使用 UDP 協(xié)議(如視頻傳輸、實(shí)時(shí)通信等)。

---

● 請(qǐng)你來說一下TCP三次握手四次揮手的過程，為什么tcp連接握手需要三次, time_wait狀態(tài)

參考回答：

1)TCP連接(三次握手)過程：

客戶端A：發(fā)送SYN連接報(bào)文，序列號(hào)為x，進(jìn)入SYNC-SENT狀態(tài)。

服務(wù)端B：發(fā)送SYN連接確認(rèn)報(bào)文(SYN=1，ACK = 1)，序列號(hào)為y(seq = y)，確認(rèn)報(bào)文x(ack = x + 1)，進(jìn)入SYNC-RCVD狀態(tài)。

客戶端A：發(fā)送ACK確認(rèn)報(bào)文(ACK = 1)，序列號(hào)為x+1(seq = x + 1)，確認(rèn)報(bào)文y+1(ack = y + 1)，進(jìn)入ESTABLISHED狀態(tài)。

服務(wù)器B：收到后進(jìn)入ESTABLISHED狀態(tài)。

2)三次握手原因：

三次握手是為了防止，客戶端的請(qǐng)求報(bào)文在網(wǎng)絡(luò)滯留，客戶端超時(shí)重傳了請(qǐng)求報(bào)文，服務(wù)端建立連接，傳輸數(shù)據(jù)，釋放連接之后，服務(wù)器又收到了客戶端滯留的請(qǐng)求報(bào)文，建立連接一直等待客戶端發(fā)送數(shù)據(jù)。

服務(wù)器對(duì)客戶端的請(qǐng)求進(jìn)行回應(yīng)(第二次握手)后，就會(huì)理所當(dāng)然的認(rèn)為連接已建立，而如果客戶端并沒有收到服務(wù)器的回應(yīng)呢？此時(shí)，客戶端仍認(rèn)為連接未建立，服務(wù)器會(huì)對(duì)已建立的連接保存必要的資源，如果大量的這種情況，服務(wù)器會(huì)崩潰。

3) TCP釋放(四次分手)過程：

服務(wù)端A：發(fā)送FIN報(bào)文(FIN = 1)，序列號(hào)為u(seq = u)，進(jìn)入FIN-WAIT 1狀態(tài)。

客戶端B：發(fā)送ACK確認(rèn)報(bào)文(ACK = 1)，序列號(hào)為v(seq = v)，確認(rèn)報(bào)文u(ack = u + 1)，進(jìn)入CLOSE-WAIT狀態(tài)，繼續(xù)傳送數(shù)據(jù)。

服務(wù)端A：收到上述報(bào)文進(jìn)入FIN-WAIT2狀態(tài)，繼續(xù)接受B傳輸?shù)臄?shù)據(jù)。

客戶端B：數(shù)據(jù)傳輸完畢后，發(fā)送FIN報(bào)文(FIN = 1，ACK = 1)，序列號(hào)為w(seq = w)，確認(rèn)報(bào)文u(ack = u + 1)，進(jìn)入LAST-ACK狀態(tài)。

服務(wù)端A：發(fā)送ACK確認(rèn)報(bào)文(ACK = 1)，序列號(hào)為u+1(seq = u + 1)，確認(rèn)報(bào)文w(ack = w + 1)，進(jìn)入TIME-WAIT狀態(tài)，等待2MSL(最長報(bào)文段壽命)，進(jìn)入CLOSED狀態(tài)。

客戶端B：收到后上述報(bào)文后進(jìn)入CLOSED狀態(tài)。

4)為什么TCP協(xié)議終止鏈接要四次？

1、當(dāng)客戶端確認(rèn)發(fā)送完數(shù)據(jù)且知道服務(wù)器已經(jīng)接收完了，想要關(guān)閉發(fā)送數(shù)據(jù)口(當(dāng)然確認(rèn)信號(hào)還是可以發(fā))，就會(huì)發(fā)FIN給服務(wù)器。

2、服務(wù)器收到客戶端發(fā)送的FIN，表示收到了，就會(huì)發(fā)送ACK回復(fù)。

3、但這時(shí)候服務(wù)器可能還在發(fā)送數(shù)據(jù)，沒有想要關(guān)閉數(shù)據(jù)口的意思，所以服務(wù)器的FIN與ACK不是同時(shí)發(fā)送的，而是等到服務(wù)器數(shù)據(jù)發(fā)送完了，才會(huì)發(fā)送FIN給客戶端。

4、客戶端收到服務(wù)器發(fā)來的FIN，知道服務(wù)器的數(shù)據(jù)也發(fā)送完了，回復(fù)ACK， 客戶端等待2MSL以后，沒有收到服務(wù)器傳來的任何消息，知道服務(wù)器已經(jīng)收到自己的ACK了，客戶端就關(guān)閉鏈接，服務(wù)器也關(guān)閉鏈接了。

5)2MSL意義：

1、保證最后一次握手報(bào)文能到B，能進(jìn)行超時(shí)重傳。

2、2MSL后，這次連接的所有報(bào)文都會(huì)消失，不會(huì)影響下一次連接。

---

● 請(qǐng)你來說一說http協(xié)議

參考回答：

1)HTTP協(xié)議：

HTTP協(xié)議是Hyper Text Transfer Protocol(超文本傳輸協(xié)議)的縮寫，是用于從萬維網(wǎng)(WWW:World Wide Web)服務(wù)器傳輸超文本到本地瀏覽器的傳送協(xié)議。

HTTP是一個(gè)基于TCP/IP通信協(xié)議來傳遞數(shù)據(jù)(HTML 文件，圖片文件，查詢結(jié)果等)。

HTTP是一個(gè)屬于應(yīng)用層的面向?qū)ο蟮膮f(xié)議，由于其簡捷、快速的方式，適用于分布式超媒體信息系統(tǒng)。它于1990年提出，經(jīng)過幾年的使用與發(fā)展，得到不斷地完善和擴(kuò)展。目前在WWW中使用的是HTTP/1.0的第六版，HTTP/1.1的規(guī)范化工作正在進(jìn)行之中，而且HTTP-NG(Next Generation of HTTP)的建議已經(jīng)提出。

HTTP協(xié)議工作于客戶端-服務(wù)端架構(gòu)為上。瀏覽器作為HTTP客戶端通過URL向HTTP服務(wù)端即WEB服務(wù)器發(fā)送所有請(qǐng)求。Web服務(wù)器根據(jù)接收到的請(qǐng)求后，向客戶端發(fā)送響應(yīng)信息。

2)HTTP協(xié)議特點(diǎn)

1、簡單快速：

客戶向服務(wù)器請(qǐng)求服務(wù)時(shí)，只需傳送請(qǐng)求方法和路徑。請(qǐng)求方法常用的有GET、HEAD、POST。每種方法規(guī)定了客戶與服務(wù)器聯(lián)系的類型不同。由于HTTP協(xié)議簡單，使得HTTP服務(wù)器的程序規(guī)模小，因而通信速度很快。

2、靈活：

HTTP允許傳輸任意類型的數(shù)據(jù)對(duì)象。正在傳輸?shù)念愋陀蒀ontent-Type加以標(biāo)記。

3、無連接：

無連接的含義是限制每次連接只處理一個(gè)請(qǐng)求。服務(wù)器處理完客戶的請(qǐng)求，并收到客戶的應(yīng)答后，即斷開連接。采用這種方式可以節(jié)省傳輸時(shí)間。

4、無狀態(tài)：

HTTP協(xié)議是無狀態(tài)協(xié)議。無狀態(tài)是指協(xié)議對(duì)于事務(wù)處理沒有記憶能力。缺少狀態(tài)意味著如果后續(xù)處理需要前面的信息，則它必須重傳，這樣可能導(dǎo)致每次連接傳送的數(shù)據(jù)量增大。另一方面，在服務(wù)器不需要先前信息時(shí)它的應(yīng)答就較快。

5、支持B/S及C/S模式。

6、默認(rèn)端口80

7、基于TCP協(xié)議

3)HTTP過程概述：

HTTP協(xié)議定義Web客戶端如何從Web服務(wù)器請(qǐng)求Web頁面，以及服務(wù)器如何把Web頁面?zhèn)魉徒o客戶端。HTTP協(xié)議采用了請(qǐng)求/響應(yīng)模型。客戶端向服務(wù)器發(fā)送一個(gè)請(qǐng)求報(bào)文，請(qǐng)求報(bào)文包含請(qǐng)求的方法、URL、協(xié)議版本、請(qǐng)求頭部和請(qǐng)求數(shù)據(jù)。服務(wù)器以一個(gè)狀態(tài)行作為響應(yīng)，響應(yīng)的內(nèi)容包括協(xié)議的版本、成功或者錯(cuò)誤代碼、服務(wù)器信息、響應(yīng)頭部和響應(yīng)數(shù)據(jù)。

HTTP 請(qǐng)求/響應(yīng)的步驟如下：

1、客戶端連接到Web服務(wù)器

一個(gè)HTTP客戶端，通常是瀏覽器，與Web服務(wù)器的HTTP端口(默認(rèn)為80)建立一個(gè)TCP套接字連接。例如，http://www.baidu.com。

2、發(fā)送HTTP請(qǐng)求

通過TCP套接字，客戶端向Web服務(wù)器發(fā)送一個(gè)文本的請(qǐng)求報(bào)文，一個(gè)請(qǐng)求報(bào)文由請(qǐng)求行、請(qǐng)求頭部、空行和請(qǐng)求數(shù)據(jù)4部分組成。

3、服務(wù)器接受請(qǐng)求并返回HTTP響應(yīng)

Web服務(wù)器解析請(qǐng)求，定位請(qǐng)求資源。服務(wù)器將資源復(fù)本寫到TCP套接字，由客戶端讀取。一個(gè)響應(yīng)由狀態(tài)行、響應(yīng)頭部、空行和響應(yīng)數(shù)據(jù)4部分組成。

4、釋放連接TCP連接

若connection 模式為close，則服務(wù)器主動(dòng)關(guān)閉TCP連接，客戶端被動(dòng)關(guān)閉連接，釋放TCP連接;若connection 模式為keepalive，則該連接會(huì)保持一段時(shí)間，在該時(shí)間內(nèi)可以繼續(xù)接收請(qǐng)求;

5、客戶端瀏覽器解析HTML內(nèi)容

客戶端瀏覽器首先解析狀態(tài)行，查看表明請(qǐng)求是否成功的狀態(tài)代碼。然后解析每一個(gè)響應(yīng)頭，響應(yīng)頭告知以下為若干字節(jié)的HTML文檔和文檔的字符集。客戶端瀏覽器讀取響應(yīng)數(shù)據(jù)HTML，根據(jù)HTML的語法對(duì)其進(jìn)行格式化，并在瀏覽器窗口中顯示。

4、舉例：

在瀏覽器地址欄鍵入U(xiǎn)RL，按下回車之后會(huì)經(jīng)歷以下流程：

1、瀏覽器向 DNS 服務(wù)器請(qǐng)求解析該 URL 中的域名所對(duì)應(yīng)的 IP 地址；

2、解析出 IP 地址后，根據(jù)該 IP 地址和默認(rèn)端口80，和服務(wù)器建立TCP連接；

3、瀏覽器發(fā)出讀取文件(URL中域名后面部分對(duì)應(yīng)的文件)的HTTP 請(qǐng)求，該請(qǐng)求報(bào)文作為 TCP 三次握手的第三個(gè)報(bào)文的數(shù)據(jù)發(fā)送給服務(wù)器；

4、服務(wù)器對(duì)瀏覽器請(qǐng)求作出響應(yīng)，并把對(duì)應(yīng)的 html 文本發(fā)送給瀏覽器；

5、釋放 TCP連接；

6、瀏覽器將該 html 文本并顯示內(nèi)容；

---

● 請(qǐng)你來說一下GET和POST的區(qū)別

參考回答：

1、概括

對(duì)于GET方式的請(qǐng)求，瀏覽器會(huì)把http header和data一并發(fā)送出去，服務(wù)器響應(yīng)200(返回?cái)?shù)據(jù))；

而對(duì)于POST，瀏覽器先發(fā)送header，服務(wù)器響應(yīng)100 continue，瀏覽器再發(fā)送data，服務(wù)器響應(yīng)200 ok(返回?cái)?shù)據(jù))

2、區(qū)別：

1、get參數(shù)通過url傳遞，post放在request body中。

2、get請(qǐng)求在url中傳遞的參數(shù)是有長度限制的，而post沒有。

3、get比post更不安全，因?yàn)閰?shù)直接暴露在url中，所以不能用來傳遞敏感信息。

4、get請(qǐng)求只能進(jìn)行url編碼，而post支持多種編碼方式。

5、get請(qǐng)求會(huì)瀏覽器主動(dòng)cache，而post支持多種編碼方式。

6、get請(qǐng)求參數(shù)會(huì)被完整保留在瀏覽歷史記錄里，而post中的參數(shù)不會(huì)被保留。

7、GET和POST本質(zhì)上就是TCP鏈接，并無差別。但是由于HTTP的規(guī)定和瀏覽器/服務(wù)器的限制，導(dǎo)致他們?cè)趹?yīng)用過程中體現(xiàn)出一些不同。

8、GET產(chǎn)生一個(gè)TCP數(shù)據(jù)包；POST產(chǎn)生兩個(gè)TCP數(shù)據(jù)包。

---

● 請(qǐng)你來說一下socket編程中服務(wù)器端和客戶端主要用到哪些函數(shù)

參考回答：

1)基于TCP的socket：

1、服務(wù)器端程序：

1創(chuàng)建一個(gè)socket，用函數(shù)socket()

2綁定IP地址、端口等信息到socket上，用函數(shù)bind()

3設(shè)置允許的最大連接數(shù)，用函數(shù)listen()

4接收客戶端上來的連接，用函數(shù)accept()

5收發(fā)數(shù)據(jù)，用函數(shù)send()和recv()，或者read()和write()

6關(guān)閉網(wǎng)絡(luò)連接

2、客戶端程序：

1創(chuàng)建一個(gè)socket，用函數(shù)socket()

2設(shè)置要連接的對(duì)方的IP地址和端口等屬性

3連接服務(wù)器，用函數(shù)connect()

4收發(fā)數(shù)據(jù)，用函數(shù)send()和recv()，或read()和write()

5關(guān)閉網(wǎng)絡(luò)連接

2)基于UDP的socket：

1、服務(wù)器端流程

1建立套接字文件描述符，使用函數(shù)socket()，生成套接字文件描述符。

2設(shè)置服務(wù)器地址和偵聽端口，初始化要綁定的網(wǎng)絡(luò)地址結(jié)構(gòu)。

3綁定偵聽端口，使用bind()函數(shù)，將套接字文件描述符和一個(gè)地址類型變量進(jìn)行綁定。

4接收客戶端的數(shù)據(jù)，使用recvfrom()函數(shù)接收客戶端的網(wǎng)絡(luò)數(shù)據(jù)。

5向客戶端發(fā)送數(shù)據(jù)，使用sendto()函數(shù)向服務(wù)器主機(jī)發(fā)送數(shù)據(jù)。

6關(guān)閉套接字，使用close()函數(shù)釋放資源。UDP協(xié)議的客戶端流程

2、客戶端流程

1建立套接字文件描述符，socket()。

2設(shè)置服務(wù)器地址和端口，struct sockaddr。

3向服務(wù)器發(fā)送數(shù)據(jù)，sendto()。

4接收服務(wù)器的數(shù)據(jù)，recvfrom()。

5關(guān)閉套接字，close()。

● 請(qǐng)你來說一下數(shù)字證書是什么，里面都包含那些內(nèi)容

參考回答：

1)概念：

數(shù)字證書是數(shù)字證書在一個(gè)身份和該身份的持有者所擁有的公/私鑰對(duì)之間建立了一種聯(lián)系，由認(rèn)證中心(CA)或者認(rèn)證中心的下級(jí)認(rèn)證中心頒發(fā)的。根證書是認(rèn)證中心與用戶建立信任關(guān)系的基礎(chǔ)。在用戶使用數(shù)字證書之前必須首先下載和安裝。

認(rèn)證中心是一家能向用戶簽發(fā)數(shù)字證書以確認(rèn)用戶身份的管理機(jī)構(gòu)。為了防止數(shù)字憑證的偽造，認(rèn)證中心的公共密鑰必須是可靠的，認(rèn)證中心必須公布其公共密鑰或由更高級(jí)別的認(rèn)證中心提供一個(gè)電子憑證來證明其公共密鑰的有效性，后一種方法導(dǎo)致了多級(jí)別認(rèn)證中心的出現(xiàn)。

2)數(shù)字證書頒發(fā)過程：

數(shù)字證書頒發(fā)過程如下：用戶產(chǎn)生了自己的密鑰對(duì)，并將公共密鑰及部分個(gè)人身份信息傳送給一家認(rèn)證中心。認(rèn)證中心在核實(shí)身份后，將執(zhí)行一些必要的步驟，以確信請(qǐng)求確實(shí)由用戶發(fā)送而來，然后，認(rèn)證中心將發(fā)給用戶一個(gè)數(shù)字證書，該證書內(nèi)附了用戶和他的密鑰等信息，同時(shí)還附有對(duì)認(rèn)證中心公共密鑰加以確認(rèn)的數(shù)字證書。當(dāng)用戶想證明其公開密鑰的合法性時(shí)，就可以提供這一數(shù)字證書。

3)內(nèi)容：

數(shù)字證書的格式普遍采用的是X.509V3國際標(biāo)準(zhǔn)，一個(gè)標(biāo)準(zhǔn)的X.509數(shù)字證書包含以下一些內(nèi)容：

1、證書的版本信息；

2、證書的序列號(hào)，每個(gè)證書都有一個(gè)唯一的證書序列號(hào)；

3、證書所使用的簽名算法；

4、證書的發(fā)行機(jī)構(gòu)名稱，命名規(guī)則一般采用X.500格式；

5、證書的有效期，通用的證書一般采用UTC時(shí)間格式；

6、證書所有人的名稱，命名規(guī)則一般采用X.500格式；

7、證書所有人的公開密鑰；

8、證書發(fā)行者對(duì)證書的簽名。

---

● 請(qǐng)你來介紹一下udp的connect函數(shù)

參考回答：

除非套接字已連接，否則異步錯(cuò)誤是不會(huì)反悔到UDP套接字的。我們確實(shí)可以給UDP套接字調(diào)用connect，然而這樣做的結(jié)果卻與TCP連接不同的是沒有三路握手過程。內(nèi)核只是檢查是否存在立即可知的錯(cuò)誤，記錄對(duì)端的IP地址和端口號(hào)，然后立即返回調(diào)用進(jìn)程。

對(duì)于已連接UDP套接字，與默認(rèn)的未連接UDP套接字相比，發(fā)生了三個(gè)變化。

其實(shí)一旦UDP套接字調(diào)用了connect系統(tǒng)調(diào)用，那么這個(gè)UDP上的連接就變成一對(duì)一的連接，但是通過這個(gè)UDP連接傳輸數(shù)據(jù)的性質(zhì)還是不變的，仍然是不可靠的UDP連接。一旦變成一對(duì)一的連接，在調(diào)用系統(tǒng)調(diào)用發(fā)送和接受數(shù)據(jù)時(shí)也就可以使用TCP那一套系統(tǒng)調(diào)用了。

1、我們?cè)僖膊荒芙o輸出操作指定目的IP地址和端口號(hào)。也就是說，我們不使用sendto，而改用write或send。寫到已連接UDP套接字上的任何內(nèi)容都自動(dòng)發(fā)送到由connect指定的協(xié)議地址。可以給已連接的UDP套接字調(diào)用sendto，但是不能指定目的地址。sendto的第五個(gè)參數(shù)必須為空指針，第六個(gè)參數(shù)應(yīng)該為0.

2、不必使用recvfrom以獲悉數(shù)據(jù)報(bào)的發(fā)送者，而改用read、recv或recvmsg。在一個(gè)已連接UDP套接字上，由內(nèi)核為輸入操作返回的數(shù)據(jù)報(bào)只有那些來自connect指定協(xié)議地址的數(shù)據(jù)報(bào)。這樣就限制一個(gè)已連接UDP套接字能且僅能與一個(gè)對(duì)端交換數(shù)據(jù)報(bào)。

3、由已連接UDP套接字引發(fā)的異步錯(cuò)誤會(huì)返回給它們所在的進(jìn)程，而未連接的UDP套接字不接收任何異步錯(cuò)誤。

來自任何其他IP地址或斷開的數(shù)據(jù)報(bào)不投遞給這個(gè)已連接套接字，因?yàn)樗鼈円丛碔P地址要么源UDP端口不與該套接字connect到的協(xié)議地址相匹配。

UDP客戶進(jìn)程或服務(wù)器進(jìn)程只在使用自己的UDP套接字與確定的唯一對(duì)端進(jìn)行通信時(shí)，才可以調(diào)用connect。調(diào)用connect的通常是UDP客戶，不過有些網(wǎng)絡(luò)應(yīng)用中的UDP服務(wù)器會(huì)與單個(gè)客戶長時(shí)間通信TFTP，這種情況下，客戶和服務(wù)器都可能調(diào)用connect。

---

● 請(qǐng)你講述一下TCP三次握手，四次揮手，以及為什么用三次握手？

參考回答：

三次握手

1.客戶端發(fā)送syn0給服務(wù)器
2.服務(wù)器收到syn0，回復(fù)syn1,ack(syn0+1)
3.客戶端收到syn1，回復(fù)ack(syn1+1)
四次揮手(這里以客戶端主動(dòng)斷開為例)
1.客戶端發(fā)送fin
2.服務(wù)端收到fin,回復(fù)ack,然后服務(wù)器去處理其他事
3.服務(wù)器事情處理完，回復(fù)fin
4.客戶端回復(fù)ack
為什么用三次握手
本來握手應(yīng)該和揮手一樣都是需要確認(rèn)兩個(gè)方向都能聯(lián)通的，本來模型應(yīng)該是：
1.客戶端發(fā)送syn0給服務(wù)器
2.服務(wù)器收到syn0，回復(fù)ack(syn0+1)
3.服務(wù)器發(fā)送syn1
3.客戶端收到syn1，回復(fù)ack(syn1+1)
因?yàn)閠cp是全雙工的，上邊的四部確認(rèn)了數(shù)據(jù)在兩個(gè)方向上都是可以正確到達(dá)的，但是2，3步?jīng)]有沒有上下的聯(lián)系，可以將其合并，加快握手效率，所有就變成了3步握手。

---

● 請(qǐng)你說一下阻塞，非阻塞，同步，異步

參考回答：

阻塞和非阻塞：調(diào)用者在事件沒有發(fā)生的時(shí)候，一直在等待事件發(fā)生，不能去處理別的任務(wù)這是阻塞。調(diào)用者在事件沒有發(fā)生的時(shí)候，可以去處理別的任務(wù)這是非阻塞。

同步和異步：調(diào)用者必須循環(huán)自去查看事件有沒有發(fā)生，這種情況是同步。調(diào)用者不用自己去查看事件有沒有發(fā)生，而是等待著注冊(cè)在事件上的回調(diào)函數(shù)通知自己，這種情況是異步

---

● 請(qǐng)你講述一下Socket編程的send() recv() accept() socket()函數(shù)？

參考回答：

send函數(shù)用來向TCP連接的另一端發(fā)送數(shù)據(jù)。客戶程序一般用send函數(shù)向服務(wù)器發(fā)送請(qǐng)求，而服務(wù)器則通常用send函數(shù)來向客戶程序發(fā)送應(yīng)答,send的作用是將要發(fā)送的數(shù)據(jù)拷貝到緩沖區(qū)，協(xié)議負(fù)責(zé)傳輸。

recv函數(shù)用來從TCP連接的另一端接收數(shù)據(jù)，當(dāng)應(yīng)用程序調(diào)用recv函數(shù)時(shí)，recv先等待s的發(fā)送緩沖中的數(shù)據(jù)被協(xié)議傳送完畢，然后從緩沖區(qū)中讀取接收到的內(nèi)容給應(yīng)用層。
accept函數(shù)用了接收一個(gè)連接，內(nèi)核維護(hù)了半連接隊(duì)列和一個(gè)已完成連接隊(duì)列，當(dāng)隊(duì)列為空的時(shí)候，accept函數(shù)阻塞，不為空的時(shí)候accept函數(shù)從上邊取下來一個(gè)已完成連接，返回一個(gè)文件描述符。

---

● 請(qǐng)你說一下http協(xié)議會(huì)話結(jié)束標(biāo)志怎么截出來？

參考回答：

看tcp連接是否有斷開的四部揮手階段。

---

● 請(qǐng)你說一說三次握手

參考回答：

1.客戶端發(fā)送syn0給服務(wù)器

2.服務(wù)器收到syn0，回復(fù)syn1,ack(syn0+1)
3.客戶端收到syn1，回復(fù)ack(syn1+1)

---

● 請(qǐng)你說一說四次揮手

參考回答：

1.客戶端發(fā)送syn0給服務(wù)器

2.服務(wù)器收到syn0，回復(fù)ack(syn0+1)
3.服務(wù)器發(fā)送syn1
4.客戶端收到syn1，回復(fù)ack(syn1+1)

---

● 請(qǐng)你說一說TCP/IP數(shù)據(jù)鏈路層的交互過程

參考回答：

網(wǎng)絡(luò)層等到數(shù)據(jù)鏈層用mac地址作為通信目標(biāo)，數(shù)據(jù)包到達(dá)網(wǎng)絡(luò)等準(zhǔn)備往數(shù)據(jù)鏈層發(fā)送的時(shí)候，首先會(huì)去自己的arp緩存表(存著ip-mac對(duì)應(yīng)關(guān)系)去查找改目標(biāo)ip的mac地址，如果查到了，就講目標(biāo)ip的mac地址封裝到鏈路層數(shù)據(jù)包的包頭。如果緩存中沒有找到，會(huì)發(fā)起一個(gè)廣播：who is ip XXX tell ip XXX,所有收到的廣播的機(jī)器看這個(gè)ip是不是自己的，如果是自己的，則以單撥的形式將自己的mac地址回復(fù)給請(qǐng)求的機(jī)器

總結(jié)

以上是生活随笔為你收集整理的vmware6.5.2序列号_备战秋招——计算机网络（2）的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。