一汽啟明java面試問題

一汽啟明java面試問題1、OSI七層模型與TCP/IP五層模型OSI七層：物理層、數(shù)據(jù)鏈路層、網(wǎng)絡(luò)層、傳輸層、會話層、表示層、應(yīng)用層TCP/IP五層：物理層、數(shù)據(jù)鏈路層、網(wǎng)絡(luò)層、傳輸層、應(yīng)用層2、常見應(yīng)用層協(xié)議和運(yùn)輸層、網(wǎng)絡(luò)層協(xié)議，以及硬件如路由器之類在哪一層應(yīng)用層：HTTP、SMTP、DNS、FTP傳輸層：TCP、UDP網(wǎng)絡(luò)層：ICMP、IP、路由器、防火墻數(shù)據(jù)鏈路層：網(wǎng)卡、網(wǎng)橋、交換機(jī)物理層：中繼器、集線器3、TCP與UDP區(qū)別和應(yīng)用場景，基于TCP的協(xié)議有哪些，基于UDP的有哪些基于TCP的協(xié)議：HTTP、FTP、SMTP基于UDP的協(xié)議：RIP、DNS、SNMP4、TCP可靠傳輸?shù)谋ＷC，擁塞控制目的和過程TCP通過：應(yīng)用數(shù)據(jù)分割、對數(shù)據(jù)包進(jìn)行編號、校驗(yàn)和、流量控制、擁塞控制、ARP協(xié)議、超時重傳等措施保證數(shù)據(jù)的可靠傳輸；擁塞控制目的：為了防止過多的數(shù)據(jù)注入到網(wǎng)絡(luò)中，避免網(wǎng)絡(luò)中的路由器、鏈路過載。擁塞控制過程：TCP發(fā)送發(fā)將維護(hù)一個擁塞窗口的狀態(tài)變量，該變量隨著網(wǎng)絡(luò)擁塞程度動態(tài)變化，通過慢開始、擁塞避免等算法減少網(wǎng)絡(luò)擁塞的發(fā)生。5、TCP粘包現(xiàn)象原因和解決方法TCP粘包是指：發(fā)送方發(fā)送的若干包數(shù)據(jù)到接收方接收時粘成一包。發(fā)送方原因：TCP默認(rèn)使用Nagle算法（主要作用：減少網(wǎng)絡(luò)中報文段的數(shù)量），而Nagle算法主要做兩件事：只有上一個分組得到確認(rèn)，才會發(fā)送下一個分組?收集多個小分組，在一個確認(rèn)到來時一起發(fā)送?Nagle算法造成了發(fā)送方可能會出現(xiàn)粘包問題。接收方原因：TCP接收到數(shù)據(jù)包時，并不會馬上交到應(yīng)用層進(jìn)行處理，或者說應(yīng)用層并不會立即處理。實(shí)際上，TCP將接收到的數(shù)據(jù)包保存在接收緩存里，然后應(yīng)用程序主動從緩存讀取收到的分組。這樣一來，如果TCP接收數(shù)據(jù)包到緩存的速度大于應(yīng)用程序從緩存中讀取數(shù)據(jù)包的速度，多個包就會被緩存，應(yīng)用程序就有可能讀取到多個首尾相接粘到一起的包。解決粘包問題：最本質(zhì)原因在與接收對等方無法分辨消息與消息之間的邊界在哪，通過使用某種方案給出邊界，例如：發(fā)送定長包。如果每個消息的大小都是一樣的，那么在接收對等方只要累計接收數(shù)據(jù)，直到數(shù)據(jù)等于一個定長的數(shù)值就將它作為一個消息。包尾加上\r\n標(biāo)記。FTP協(xié)議正是這么做的。但問題在于如果數(shù)據(jù)正文中也含有\(zhòng)r\n，則會誤判為消息的邊界。包頭加上包體長度。包頭是定長的4個字節(jié)，說明了包體的長度。接收對等方先接收包體長度，依據(jù)包體長度來接收包體。6、TCP三次握手過程以及每次握手后的狀態(tài)改變，為什么三次？為什么兩次不行？三次握手過程：客戶端——發(fā)送帶有SYN標(biāo)志的數(shù)據(jù)包——服務(wù)端

一次握手

Client進(jìn)入synsent狀態(tài)。?服務(wù)端——發(fā)送帶有SYN/ACK標(biāo)志的數(shù)據(jù)包——客戶端

二次握手

服務(wù)端進(jìn)入syn_rcvd?？蛻舳恕l(fā)送帶有ACK標(biāo)志的數(shù)據(jù)包——服務(wù)端

三次握手

連接就進(jìn)入Established狀態(tài)。為什么三次：主要是為了建立可靠的通信信道，保證客戶端與服務(wù)端同時具備發(fā)送、接收數(shù)據(jù)的能力為什么兩次不行？?1、防止已失效的請求報文又傳送到了服務(wù)端，建立了多余的鏈接，浪費(fèi)資源。2、兩次握手只能保證單向連接是暢通的。（為了實(shí)現(xiàn)可靠數(shù)據(jù)傳輸，TCP協(xié)議的通信雙方，都必須維護(hù)一個序列號，以標(biāo)識發(fā)送出去的數(shù)據(jù)包中，哪些是已經(jīng)被對方收到的。三次握手的過程即是通信雙方相互告知序列號起始值，并確認(rèn)對方已經(jīng)收到了序列號起始值的必經(jīng)步驟；如果只是兩次握手，至多只有連接發(fā)起方的起始序列號能被確認(rèn)，另一方選擇的序列號則得不到確認(rèn)）7、TCP四次揮手過程以及狀態(tài)改變，為什么四次？CLOSE-WAIT和TIME-WAIT存在的意義？如何查看TIME-WAIT狀態(tài)的鏈接數(shù)量？為什么會TIME-WAIT過多？解決方法是怎樣的？四次揮手過程：客戶端——發(fā)送帶有FIN標(biāo)志的數(shù)據(jù)包——服務(wù)端，關(guān)閉與服務(wù)端的連接，客戶端進(jìn)入FIN-WAIT-1狀態(tài)服務(wù)端收到這個FIN，它發(fā)回?個ACK，確認(rèn)序號為收到的序號加1，服務(wù)端就進(jìn)入了CLOSE-WAIT狀態(tài)服務(wù)端——發(fā)送?個FIN數(shù)據(jù)包——客戶端，關(guān)閉與客戶端的連接，客戶端就進(jìn)入FIN-WAIT-2狀態(tài)客戶端收到這個FIN，發(fā)回ACK報?確認(rèn)，并將確認(rèn)序號設(shè)置為收到序號加1，TIME-WAIT狀態(tài)為什么四次：因?yàn)樾枰_?？蛻舳伺c服務(wù)端的數(shù)據(jù)能夠完成傳輸。CLOSE-WAIT：這種狀態(tài)的含義其實(shí)是表示在等待關(guān)閉TIME-WAIT：為了解決網(wǎng)絡(luò)的丟包和網(wǎng)絡(luò)不穩(wěn)定所帶來的其他問題，確保連接方能在時間范圍內(nèi)，關(guān)閉自己的連接。如何查看TIME-WAIT狀態(tài)的鏈接數(shù)量？netstat-an|grepTIME_WAIT|wc-l查看連接數(shù)等待time_wait狀態(tài)連