網(wǎng)絡(luò)面試集
一偶洋、TCP/UDP
1饲趋、UDP與TCP的區(qū)別
? ? ? ? ?TCP（TransmissionControl Protocol 傳輸控制協(xié)議）是一種面向連接的幽邓、可靠的摊册、基于字節(jié)流的傳輸層通信協(xié)議。
???????? UDP是User Datagram Protocol颊艳，一種無連接的傳輸層協(xié)議，提供面向事務(wù)的簡單不可靠信息傳送服務(wù)忘分∑逭恚可靠性由上層應(yīng)用實現(xiàn)，所以要實現(xiàn)UDP可靠性傳輸妒峦，必須通過應(yīng)用層來實現(xiàn)和控制重斑。
? ? ? ? ?TCP是面向連接的，由于TCP連接需要三次握手肯骇，所以能夠最低限度的降低風(fēng)險窥浪，保證連接的可靠性。
? ? ? ? ?UDP不是面向連接的笛丙，UDP建立連接前不需要與對象建立連接漾脂，無論是發(fā)送還是接收，都沒有發(fā)送確認信號胚鸯。所以說udp是不可靠的骨稿。
????????由于UDP不需要進行確認連接，使得UDP的開銷更小姜钳，傳輸速率更高坦冠，所以實時行更好。
2哥桥、TCP如何實現(xiàn)可靠性傳輸辙浑？
? ? ? ? ? 確認機制、重傳機制拟糕、滑動窗口判呕。
? ? ??????TCP可靠傳輸原理實現(xiàn)（滑動窗口）。
確認和重傳：接收方收到報文后就會進行確認已卸，發(fā)送方一段時間沒有收到確認就會重傳佛玄。 數(shù)據(jù)校驗。 數(shù)據(jù)合理分片與排序累澡，TCP會對數(shù)據(jù)進行分片梦抢，接收方會緩存為按序到達的數(shù)據(jù)，重新排序后再提交給應(yīng)用層愧哟。 流程控制：當接收方來不及接收發(fā)送的數(shù)據(jù)時奥吩，則會提示發(fā)送方降低發(fā)送的速度哼蛆，防止包丟失。 擁塞控制：當網(wǎng)絡(luò)發(fā)生擁塞時霞赫，減少數(shù)據(jù)的發(fā)送腮介。
? ? ? ? ?TCP擁塞控制。
????????TCP流量控制端衰。
3叠洗、如何設(shè)計在 UDP 上層保證 UDP 的可靠性傳輸？
? ??????UDP它不屬于連接型協(xié)議旅东，因而具有資源消耗小灭抑，處理速度快的優(yōu)點，所以通常音頻抵代、視頻和普通數(shù)據(jù)在傳送時使用UDP較多腾节，因為它們即使偶爾丟失一兩個數(shù)據(jù)包，也不會對接收結(jié)果產(chǎn)生太大影響荤牍。
???????? 傳輸層無法保證數(shù)據(jù)的可靠傳輸案腺，只能通過應(yīng)用層來實現(xiàn)了。實現(xiàn)的方式可以參照tcp可靠性傳輸?shù)姆绞娇党常皇菍崿F(xiàn)不在傳輸層劈榨，實現(xiàn)轉(zhuǎn)移到了應(yīng)用層。
???????? 實現(xiàn)確認機制涎才、重傳機制鞋既、窗口確認機制。
???????? 如果你不利用linux協(xié)議棧以及上層socket機制耍铜，自己通過抓包和發(fā)包的方式去實現(xiàn)可靠性傳輸邑闺，那么必須實現(xiàn)如下功能：
???????? 發(fā)送：包的分片、包確認棕兼、包的重發(fā)
???????? 接收：包的調(diào)序陡舅、包的序號確認
???????? 目前有如下開源程序利用udp實現(xiàn)了可靠的數(shù)據(jù)傳輸。分別為RUDP伴挚、RTP靶衍、UDT。
4茎芋、TCP的三次握手和四次揮手
置位概念：根據(jù)TCP的包頭字段颅眶，存在3個重要的標識ACK、SYN田弥、FIN?
ACK：表示驗證字段?
SYN：位數(shù)置1涛酗，表示建立TCP連接?
FIN：位數(shù)置1，表示斷開TCP連接
【問題1】為什么連接的時候是三次握手扮念，關(guān)閉的時候卻是四次握手垒在？
答：因為當Server端收到Client端的SYN連接請求報文后，可以直接發(fā)送SYN+ACK報文扔亥。其中ACK報文是用來應(yīng)答的场躯，SYN報文是用來同步的。但是關(guān)閉連接時旅挤，當Server端收到FIN報文時踢关，很可能并不會立即關(guān)閉SOCKET，所以只能先回復(fù)一個ACK報文粘茄，告訴Client端签舞，”你發(fā)的FIN報文我收到了”秕脓。只有等到我Server端所有的報文都發(fā)送完了，我才能發(fā)送FIN報文儒搭，因此不能一起發(fā)送吠架。故需要四步握手。
【問題2】為什么TIME_WAIT狀態(tài)需要經(jīng)過2MSL(最大報文段生存時間)才能返回到CLOSE狀態(tài)搂鲫？
答：雖然按道理傍药，四個報文都發(fā)送完畢，我們可以直接進入CLOSE狀態(tài)了魂仍，但是我們必須假象網(wǎng)絡(luò)是不可靠的拐辽，有可以最后一個ACK丟失。所以TIME_WAIT狀態(tài)就是用來重發(fā)可能丟失的ACK報文擦酌。在Client發(fā)送出最后的ACK回復(fù)俱诸，但該ACK可能丟失。Server如果沒有收到ACK赊舶，將不斷重復(fù)發(fā)送FIN片段睁搭。所以Client不能立即關(guān)閉，它必須確認Server接收到了該ACK笼平。Client會在發(fā)送出ACK之后進入到TIME_WAIT狀態(tài)介袜。Client會設(shè)置一個計時器，等待2MSL的時間出吹。如果在該時間內(nèi)再次收到FIN，那么Client會重發(fā)ACK并再次等待2MSL辙喂。所謂的2MSL是兩倍的MSL(Maximum Segment Lifetime)捶牢。MSL指一個片段在網(wǎng)絡(luò)中最大的存活時間，2MSL就是一個發(fā)送和一個回復(fù)所需的最大時間巍耗。如果直到2MSL秋麸，Client都沒有再次收到FIN，那么Client推斷ACK已經(jīng)被成功接收炬太，則結(jié)束TCP連接灸蟆。
【問題3】為什么不能用兩次握手進行連接？
答：3次握手完成兩個重要的功能亲族，既要雙方做好發(fā)送數(shù)據(jù)的準備工作(雙方都知道彼此已準備好)炒考，也要允許雙方就初始序列號進行協(xié)商，這個序列號在握手過程中被發(fā)送和確認霎迫。
現(xiàn)在把三次握手改成僅需要兩次握手斋枢，死鎖是可能發(fā)生的。作為例子知给，考慮計算機S和C之間的通信瓤帚，假定C給S發(fā)送一個連接請求分組描姚，S收到了這個分組，并發(fā) 送了確認應(yīng)答分組戈次。按照兩次握手的協(xié)定轩勘，S認為連接已經(jīng)成功地建立了，可以開始發(fā)送數(shù)據(jù)分組怯邪“硌埃可是，C在S的應(yīng)答分組在傳輸中被丟失的情況下擎颖，將不知道S 是否已準備好榛斯，不知道S建立什么樣的序列號，C甚至懷疑S是否收到自己的連接請求分組搂捧。在這種情況下驮俗，C認為連接還未建立成功，將忽略S發(fā)來的任何數(shù)據(jù)分 組允跑，只等待連接確認應(yīng)答分組王凑。而S在發(fā)出的分組超時后，重復(fù)發(fā)送同樣的分組聋丝。這樣就形成了死鎖索烹。
【問題4】如果已經(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/HTTPS
1.HTTP與HTTPS有什么區(qū)別脖捻？
????????https協(xié)議需要到ca申請證書，一般免費證書較少兆衅，因而需要一定費用地沮。
????????http是超文本傳輸協(xié)議嗜浮，信息是明文傳輸，https則是具有安全性的ssl加密傳輸協(xié)議摩疑。
????????http和https使用的是完全不同的連接方式危融，用的端口也不一樣，前者是80雷袋，后者是443吉殃。
????????http的連接很簡單，是無狀態(tài)的楷怒；HTTPS協(xié)議是由SSL+HTTP協(xié)議構(gòu)建的可進行加密傳輸蛋勺、身份認證的網(wǎng)絡(luò)協(xié)議，比http協(xié)議安全鸠删。
https實現(xiàn)原理：
????????客戶使用https的URL訪問Web服務(wù)器抱完，要求與Web服務(wù)器建立SSL連接。
????????Web服務(wù)器收到客戶端請求后刃泡，會將網(wǎng)站的證書信息（證書中包含公鑰）傳送一份給客戶端巧娱。
????????客戶端的瀏覽器與Web服務(wù)器開始協(xié)商SSL連接的安全等級，也就是信息加密的等級烘贴。
????????客戶端的瀏覽器根據(jù)雙方同意的安全等級禁添，建立會話密鑰，然后利用網(wǎng)站的公鑰將會話密鑰加密桨踪，并傳送給網(wǎng)站老翘。
????????Web服務(wù)器利用自己的私鑰解密出會話密鑰。
????????Web服務(wù)器利用會話密鑰加密與客戶端之間的通信锻离。
HTTP鏈接的特點
????????HTTP連接最顯著的特點是客戶端發(fā)送的每次請求都需要服務(wù)器回送響應(yīng)铺峭，在請求結(jié)束后，會主動釋放連接纳账。從建立連接到關(guān)閉連接的過程稱為“一次連接”。
2捺疼、Http位于TCP/IP模型中的第幾層疏虫？為什么說Http是可靠的數(shù)據(jù)傳輸協(xié)議？
tcp/ip的五層模型：
????????從下到上：物理層->數(shù)據(jù)鏈路層->網(wǎng)絡(luò)層->傳輸層->應(yīng)用層
????????其中tcp/ip位于模型中的網(wǎng)絡(luò)層啤呼，處于同一層的還有ICMP（網(wǎng)絡(luò)控制信息協(xié)議）卧秘。http位于模型中的應(yīng)用層
????????由于tcp/ip是面向連接的可靠協(xié)議，而http是在傳輸層基于tcp/ip協(xié)議的官扣，所以說http是可靠的數(shù)據(jù)傳輸協(xié)議翅敌。
3、http協(xié)議中g(shù)et和post的區(qū)別
????????Get：是以實體的方式得到由請求URI所指定資源的信息惕蹄，如果請求URI只是一個數(shù)據(jù)產(chǎn)生過程蚯涮，那么最終要在響應(yīng)實體中返回的是處理過程的結(jié)果所指向的資源治专，而不是處理過程的描述。
Post：用來向目的服務(wù)器發(fā)出請求遭顶，要求它接受被附在請求后的實體张峰，并把它當作請求隊列中請求URI所指定資源的附加新子項，Post被設(shè)計成用統(tǒng)一的方法實現(xiàn)下列功能：
1：對現(xiàn)有資源的解釋
2：向電子公告欄棒旗、新聞組喘批、郵件列表或類似討論組發(fā)信息。
3：提交數(shù)據(jù)塊
4：通過附加操作來擴展數(shù)據(jù)庫
從上面描述可以看出铣揉，Get是向服務(wù)器發(fā)索取數(shù)據(jù)的一種請求饶深；而Post是向服務(wù)器提交數(shù)據(jù)的一種請求，要提交的數(shù)據(jù)位于信息頭后面的實體中逛拱。
4敌厘、HTTP請求方式的選擇
HttpClient與HttpUrlConnection的區(qū)別
????????首先HttpClient和HttpUrlConnection 這兩種方式都支持Https協(xié)議，都是以流的形式進行上傳或者下載數(shù)據(jù)橘券，也可以說是以流的形式進行數(shù)據(jù)的傳輸额湘，還有ipv6,以及連接池等功能。HttpClient這個擁有非常多的API旁舰，所以如果想要進行擴展的話锋华，并且不破壞它的兼容性的話，很難進行擴展箭窜，也就是這個原因毯焕，Google在Android6.0的時候，直接就棄用了這個HttpClient.
????????而HttpUrlConnection相對來說就是比較輕量級了磺樱，API比較少纳猫，容易擴展，并且能夠滿足Android大部分的數(shù)據(jù)傳輸竹捉。比較經(jīng)典的一個框架volley芜辕，在2.3版本以前都是使用HttpClient,在2.3以后就使用了HttpUrlConnection。
三块差、網(wǎng)絡(luò)協(xié)議層
1侵续、OSI，TCP/IP憨闰，五層協(xié)議的體系結(jié)構(gòu)状蜗，以及各層協(xié)議
OSI分層 （7層）：物理層、數(shù)據(jù)鏈路層鹉动、網(wǎng)絡(luò)層轧坎、傳輸層、會話層泽示、表示層缸血、應(yīng)用層蜜氨。
TCP/IP分層（4層）：網(wǎng)絡(luò)接口層、 網(wǎng)際層属百、運輸層记劝、 應(yīng)用層。
五層協(xié)議? ? （5層）：物理層族扰、數(shù)據(jù)鏈路層厌丑、網(wǎng)絡(luò)層、運輸層渔呵、 應(yīng)用層怒竿。
每一層的協(xié)議如下：
物理層：RJ45、CLOCK扩氢、IEEE802.3? ? （中繼器耕驰，集線器，網(wǎng)關(guān)）
數(shù)據(jù)鏈路：PPP录豺、FR朦肘、HDLC、VLAN双饥、MAC? （網(wǎng)橋媒抠，交換機）
網(wǎng)絡(luò)層：IP、ICMP咏花、ARP趴生、RARP、OSPF、IPX、RIP券敌、IGRP、 （路由器）
傳輸層：TCP浸踩、UDP、SPX
會話層：NFS统求、SQL检碗、NETBIOS、RPC
表示層：JPEG球订、MPEG后裸、ASII
應(yīng)用層：FTP瑰钮、DNS冒滩、Telnet、SMTP浪谴、HTTP开睡、WWW因苹、NFS
2、長連接和短連接操作
短連接的操作步驟是：
????建立連接——數(shù)據(jù)傳輸——關(guān)閉連接…建立連接——數(shù)據(jù)傳輸——關(guān)閉連接
長連接的操作步驟是：
????建立連接——數(shù)據(jù)傳輸…（保持連接）…數(shù)據(jù)傳輸——關(guān)閉連接
長連接和短連接的優(yōu)點和缺點
由上可以看出篇恒，長連接可以省去較多的TCP建立和關(guān)閉的操作扶檐，減少浪費，節(jié)約時間胁艰。對于頻繁請求資源的客戶來說款筑，較適用長連接。不過這里存在一個問題腾么，存活功能的探測周期太長奈梳，還有就是它只是探測TCP連接的存活，屬于比較斯文的做法解虱，遇到惡意的連接時攘须，保活功能就不夠使了殴泰。在長連接的應(yīng)用場景下于宙，client端一般不會主動關(guān)閉它們之間的連接，Client與server之間的連接如果一直不關(guān)閉的話悍汛，會存在一個問題捞魁，隨著客戶端連接越來越多，server早晚有扛不住的時候员凝，這時候server端需要采取一些策略署驻，如關(guān)閉一些長時間沒有讀寫事件發(fā)生的連接，這樣可 以避免一些惡意連接導(dǎo)致server端服務(wù)受損健霹；如果條件再允許就可以以客戶端機器為顆粒度旺上，限制每個客戶端的最大長連接數(shù)，這樣可以完全避免某個蛋疼的客戶端連累后端服務(wù)糖埋。
短連接對于服務(wù)器來說管理較為簡單宣吱，存在的連接都是有用的連接，不需要額外的控制手段瞳别。但如果客戶請求頻繁征候，將在TCP的建立和關(guān)閉操作上浪費時間和帶寬。
長連接和短連接的產(chǎn)生在于client和server采取的關(guān)閉策略祟敛，具體的應(yīng)用場景采用具體的策略疤坝，沒有十全十美的選擇，只有合適的選擇馆铁。
什么時候用長連接跑揉，短連接？
長連接多用于操作頻繁，點對點的通訊历谍，而且連接數(shù)不能太多情況现拒，。每個TCP連接都需要三步握手望侈，這需要時間印蔬，如果每個操作都是先連接，再操作的話那么處理速度會降低很多脱衙，所以每個操作完后都不斷開侥猬，次處理時直接發(fā)送數(shù)據(jù)包就OK了，不用建立TCP連接捐韩。例如：數(shù)據(jù)庫的連接用長連接陵究， 如果用短連接頻繁的通信會造成socket錯誤，而且頻繁的socket 創(chuàng)建也是對資源的浪費奥帘。
而像WEB網(wǎng)站的http服務(wù)一般都用短鏈接铜邮，因為長連接對于服務(wù)端來說會耗費一定的資源，而像WEB網(wǎng)站這么頻繁的成千上萬甚至上億客戶端的連接用短連接會更省一些資源寨蹋，如果用長連接松蒜，而且同時有成千上萬的用戶，如果每個用戶都占用一個連接的話已旧，那可想而知吧秸苗。所以并發(fā)量大，但每個用戶無需頻繁操作情況下需用短連好运褪。
3惊楼、Socket建立網(wǎng)絡(luò)連接的步驟
????????建立Socket連接至少需要一對套接字，其中一個運行與客戶端—ClientSocket秸讹，一個運行于服務(wù)端—ServiceSocket
????????服務(wù)器監(jiān)聽：服務(wù)器端套接字并不定位具體的客戶端套接字檀咙，而是處于等待連接的狀態(tài)，實時監(jiān)控網(wǎng)絡(luò)狀態(tài)璃诀，等待客戶端的連接請求弧可。
????????客戶端請求：指客戶端的套接字提出連接請求，要連接的目標是服務(wù)器端的套接字劣欢。注意：客戶端的套接字必須描述他要連接的服務(wù)器的套接字棕诵，指出服務(wù)器套接字的地址和端口號，然后就像服務(wù)器端套接字提出連接請求凿将。
????????連接確認：當服務(wù)器端套接字監(jiān)聽到客戶端套接字的連接請求時校套，就響應(yīng)客戶端套接字的請求，建立一個新的線程牧抵，把服務(wù)器端套接字的描述發(fā)給客戶端笛匙，一旦客戶端確認了此描述，雙方就正式建立連接。而服務(wù)端套接字則繼續(xù)處于監(jiān)聽狀態(tài)膳算，繼續(xù)接收其他客戶端套接字的連接請求。
