1. 瀏覽器輸入 URL 發(fā)生了什么?
[圖片上傳失敗...(image-1e337c-1588931639592)]
DNS 解析：瀏覽器查詢 DNS惭每，獲取域名對應的 IP 地址：具體過程包括瀏覽器搜索自身的 DNS 緩存辆雾、搜索操作系統(tǒng)的 DNS 緩存捺癞、讀取本地的 Host 文件和向本地 DNS 服務器進行查詢等。對于向本地 DNS 服務器進行查詢省艳，如果要查詢的域名包含在本地配置區(qū)域資源中，則返回解析結果給客戶機派昧，完成域名解析(此解析具有權威性)特笋；如果要查詢的域名不由本地 DNS 服務器區(qū)域解析剃浇，但該服務器已緩存了此網(wǎng)址映射關系，則調用這個 IP 地址映射猎物，完成域名解析（此解析不具有權威性）虎囚。如果本地域名服務器并未緩存該網(wǎng)址映射關系，那么將根據(jù)其設置發(fā)起遞歸查詢或者迭代查詢蔫磨；
TCP 連接：瀏覽器獲得域名對應的 IP 地址以后淘讥，瀏覽器向服務器請求建立鏈接，發(fā)起三次握手堤如；
發(fā)送 HTTP 請求：TCP 連接建立起來后蒲列，瀏覽器向服務器發(fā)送 HTTP 請求窒朋；
服務器處理請求并返回 HTTP 報文：服務器接收到這個請求，并根據(jù)路徑參數(shù)映射到特定的請求處理器進行處理蝗岖，并將處理結果及相應的視圖返回給瀏覽器侥猩；
瀏覽器解析渲染頁面：瀏覽器解析并渲染視圖，若遇到對 js 文件抵赢、css 文件及圖片等靜態(tài)資源的引用欺劳，則重復上述步驟并向服務器請求這些資源；瀏覽器根據(jù)其請求到的資源瓣俯、數(shù)據(jù)渲染頁面杰标，最終向用戶呈現(xiàn)一個完整的頁面。
連接結束彩匕。
2. TCP 和 UDP 區(qū)別?
[圖片上傳失敗...(image-96a269-1588931639593)]
UDP 在傳送數(shù)據(jù)之前不需要先建立連接腔剂，遠地主機在收到 UDP 報文后，不需要給出任何確認驼仪。雖然 UDP 不提供可靠交付掸犬，但在某些情況下 UDP 確是一種最有效的工作方式（一般用于即時通信），比如：QQ 語音绪爸、 QQ 視頻 湾碎、直播等等
TCP 提供面向連接的服務。在傳送數(shù)據(jù)之前必須先建立連接奠货，數(shù)據(jù)傳送結束后要釋放連接介褥。TCP 不提供廣播或多播服務。由于 TCP 要提供可靠的递惋，面向連接的傳輸服務（TCP 的可靠體現(xiàn)在 TCP 在傳遞數(shù)據(jù)之前柔滔，會有三次握手來建立連接，而且在數(shù)據(jù)傳遞時萍虽，有確認睛廊、窗口、重傳杉编、擁塞控制機制超全，在數(shù)據(jù)傳完后，還會斷開連接用來節(jié)約系統(tǒng)資源）邓馒，這一難以避免增加了許多開銷嘶朱，如確認，流量控制光酣，計時器以及連接管理等见咒。這不僅使協(xié)議數(shù)據(jù)單元的首部增大很多，還要占用許多處理機資源挂疆。TCP 一般用于文件傳輸改览、發(fā)送和接收郵件下翎、遠程登錄等場景。
3. TCP 如何保證傳輸可靠性?
- 應用數(shù)據(jù)被分割成 TCP 認為最適合發(fā)送的數(shù)據(jù)塊宝当。
- TCP 給發(fā)送的每一個包進行編號视事，接收方對數(shù)據(jù)包進行排序，把有序數(shù)據(jù)傳送給應用層庆揩。
- 校驗和： TCP 將保持它首部和數(shù)據(jù)的檢驗和俐东。這是一個端到端的檢驗和，目的是檢測數(shù)據(jù)在傳輸過程中的任何變化订晌。如果收到段的檢驗和有差錯虏辫，TCP 將丟棄這個報文段和不確認收到此報文段。
TCP 的接收端會丟棄重復的數(shù)據(jù)锈拨。 - 流量控制：TCP使用的滑動窗口進行流量控制砌庄，可以累積確認。TCP 連接的每一方都有固定大小的緩沖空間奕枢，TCP 的接收端只允許發(fā)送端發(fā)送接收端緩沖區(qū)能接納的數(shù)據(jù)娄昆。當接收方來不及處理發(fā)送方的數(shù)據(jù)，能提示發(fā)送方降低發(fā)送的速率缝彬，防止包丟失萌焰。TCP 使用的流量控制協(xié)議是可變大小的滑動窗口協(xié)議。（TCP 利用滑動窗口實現(xiàn)流量控制）谷浅，窗口的大小是在TCP首部有字段進行控制扒俯。當然在后來增加窗口擴大選項。2^16
- 擁塞控制： 當網(wǎng)絡擁塞時一疯，減少數(shù)據(jù)的發(fā)送陵珍。
慢開始，剛開始時不清楚網(wǎng)絡的情況违施，先將擁塞窗口設置為最大報文字段的值，然后慢開始瑟幕，每次進行加倍磕蒲，直到到達門限。
擁塞避免只盹，是每次進行加1辣往，直到網(wǎng)絡出現(xiàn)超時。門限變?yōu)閾砣囊话耄?/li>
快重傳殖卑，接收方收到一個失序的報文段站削，立即進行重復確定，如果接受方收到三個重復ack,不必等到重傳計時器到期孵稽，立即進行重傳许起。
快恢復十偶，在收到三個冗余ack,雖然存在報文丟失，但是網(wǎng)絡可能沒有阻塞园细，窗口減半惦积，執(zhí)行擁塞避免算法。
ARQ 協(xié)議： 也是為了實現(xiàn)可靠傳輸?shù)拿推担幕驹砭褪敲堪l(fā)完一個分組就停止發(fā)送狮崩，等待對方確認。在收到確認后再發(fā)下一個分組鹿寻。
超時重傳： 當 TCP 發(fā)出一個段后睦柴，它啟動一個定時器，等待目的端確認收到這個報文段毡熏。如果不能及時收到一個確認坦敌，將重發(fā)這個報文段。
流量控制與擁塞控制的區(qū)別招刹，流量控制是點對點的恬试，擁塞控制是全局的；
發(fā)端窗口的大小取決于收端的窗口大小rwnd（TCP報文的窗口大小字段）和擁塞窗口大小cwnd（見擁塞控制）
發(fā)端窗口大小 = min{ rwnd , cwnd };
4. TCP三次握手的過程疯暑？
最初客戶端和服務端都處于 CLOSED(關閉) 狀態(tài)训柴。本例中 A（Client） 主動打開連接，B（Server） 被動打開連接妇拯。
一開始幻馁，B 的 TCP 服務器進程首先創(chuàng)建傳輸控制塊TCB，準備接受客戶端進程的連接請求越锈。然后服務端進程就處于 LISTEN(監(jiān)聽) 狀態(tài)仗嗦，等待客戶端的連接請求。如有甘凭，立即作出響應稀拐。
第一次握手：A 的 TCP 客戶端進程也是首先創(chuàng)建傳輸控制塊 TCB。然后丹弱，在打算建立 TCP 連接時德撬，向 B 發(fā)出連接請求報文段，這時首部中的同步位 SYN=1躲胳，同時選擇一個初始序號 seq = x蜓洪。TCP 規(guī)定，SYN 報文段（即 SYN = 1 的報文段）不能攜帶數(shù)據(jù)坯苹，但要消耗掉一個序號隆檀。這時，TCP 客戶進程進入 SYN-SENT（同步已發(fā)送）狀態(tài)。
第二次握手：B 收到連接請求報文后恐仑，如果同意建立連接泉坐，則向 A 發(fā)送確認。在確認報文段中應把 SYN 位和 ACK 位都置 1菊霜，確認號是 ack = x + 1坚冀，同時也為自己選擇一個初始序號 seq = y。請注意鉴逞，這個報文段也不能攜帶數(shù)據(jù)记某，但同樣要消耗掉一個序號。這時 TCP 服務端進程進入 SYN-RCVD（同步收到）狀態(tài)构捡。
第三次握手：TCP 客戶進程收到 B 的確認后液南，還要向 B 給出確認。確認報文段的 ACK 置 1勾徽，確認號 ack = y + 1滑凉，而自己的序號 seq = x + 1。這時 ACK 報文段可以攜帶數(shù)據(jù)喘帚。但如果不攜帶數(shù)據(jù)則不消耗序號畅姊，這種情況下，下一個數(shù)據(jù)報文段的序號仍是 seq = x + 1吹由。這時若未，TCP 連接已經(jīng)建立，A 進入 ESTABLISHED（已建立連接）狀態(tài)倾鲫。
5. 為什么兩次握手不可以呢粗合？
為了防止已經(jīng)失效的連接請求報文段突然又傳送到了 B，因而產(chǎn)生錯誤乌昔。比如下面這種情況：A 發(fā)出的第一個連接請求報文段并沒有丟失隙疚，而是在網(wǎng)路結點長時間滯留了，以致于延誤到連接釋放以后的某個時間段才到達 B磕道。本來這是一個早已失效的報文段供屉。但是 B 收到此失效的鏈接請求報文段后，就誤認為 A 又發(fā)出一次新的連接請求溺蕉。于是就向 A 發(fā)出確認報文段伶丐，同意建立連接。
對于上面這種情況焙贷，如果不進行第三次握手，B 發(fā)出確認后就認為新的運輸連接已經(jīng)建立了贿堰，并一直等待 A 發(fā)來數(shù)據(jù)辙芍。B 的許多資源就這樣白白浪費了。
如果采用了三次握手，由于 A 實際上并沒有發(fā)出建立連接請求故硅，所以不會理睬 B 的確認庶灿，也不會向 B 發(fā)送數(shù)據(jù)。B 由于收不到確認吃衅，就知道 A 并沒有要求建立連接往踢。
6. 為什么不需要四次握手？
有人可能會說 A 發(fā)出第三次握手的信息后在沒有接收到 B 的請求就已經(jīng)進入了連接狀態(tài)徘层，那如果 A 的這個確認包丟失或者滯留了怎么辦峻呕？
我們需要明白一點，完全可靠的通信協(xié)議是不存在的趣效。在經(jīng)過三次握手之后瘦癌，客戶端和服務端已經(jīng)可以確認之前的通信狀況，都收到了確認信息跷敬。所以即便再增加握手次數(shù)也不能保證后面的通信完全可靠讯私，所以是沒有必要的。
7. Server 端收到 Client 端的 SYN 后西傀，為什么還要傳回 SYN斤寇？
接收端傳回發(fā)送端所發(fā)送的 SYN 是為了告訴發(fā)送端，我接收到的信息確實就是你所發(fā)送的信號了拥褂。
SYN 是 TCP / IP 建立連接時使用的握手信號娘锁。在客戶機和服務器之間建立正常的 TCP 網(wǎng)絡連接時，客戶機首先發(fā)出一個 SYN 消息肿仑，服務器使用 SYN-ACK 應答表示接收到了這個消息致盟，最后客戶機再以 ACK(Acknowledgement[漢譯：確認字符，在數(shù)據(jù)通信傳輸中尤慰，接收站發(fā)給發(fā)送站的一種傳輸控制字符馏锡。它表示確認發(fā)來的數(shù)據(jù)已經(jīng)接受無誤]）消息響應。這樣在客戶機和服務器之間才能建立起可靠的 TCP 連接伟端，數(shù)據(jù)才可以在客戶機和服務器之間傳遞杯道。
8. 傳了 SYN，為什么還要傳 ACK责蝠？
雙方通信無誤必須是兩者互相發(fā)送信息都無誤党巾。傳了 SYN，證明發(fā)送方到接收方的通道沒有問題霜医，但是接收方到發(fā)送方的通道還需要 ACK 信號來進行驗證齿拂。
9. TCP 四次揮手的過程？
第一次揮手：A 的應用進程先向其 TCP 發(fā)出連接釋放報文段肴敛，并停止再發(fā)送數(shù)據(jù)署海，主動關閉 TCP 連接吗购。A 把連接釋放報文段首部的終止控制位 FIN 置 1，其序號 seq = u（等于前面已傳送過的數(shù)據(jù)的最后一個字節(jié)的序號加 1）砸狞，這時 A 進入 FIN-WAIT-1（終止等待1）狀態(tài)捻勉，等待 B 的確認。請注意：TCP 規(guī)定刀森，F(xiàn)IN 報文段即使不攜帶數(shù)據(jù)踱启，也將消耗掉一個序號。
第二次揮手：B 收到連接釋放報文段后立即發(fā)出確認研底，確認號是 ack = u + 1埠偿，而這個報文段自己的序號是 v（等于 B 前面已經(jīng)傳送過的數(shù)據(jù)的最后一個字節(jié)的序號加1），然后 B 就進入 CLOSE-WAIT（關閉等待）狀態(tài)飘哨。TCP 服務端進程這時應通知高層應用進程胚想，因而從 A 到 B 這個方向的連接就釋放了，這時的 TCP 連接處于半關閉（half-close）狀態(tài)芽隆，即 A 已經(jīng)沒有數(shù)據(jù)要發(fā)送了浊服，但 B 若發(fā)送數(shù)據(jù)，A 仍要接收胚吁。也就是說牙躺，從 B 到 A 這個方向的連接并未關閉，這個狀態(tài)可能會持續(xù)一段時間腕扶。A 收到來自 B 的確認后孽拷，就進入 FIN-WAIT-2(終止等待2)狀態(tài)，等待 B 發(fā)出的連接釋放報文段半抱。
第三次揮手：若 B 已經(jīng)沒有要向 A 發(fā)送的數(shù)據(jù)脓恕，其應用進程就通知 TCP 釋放連接。這時 B 發(fā)出的連接釋放報文段必須使 FIN = 1窿侈。假定 B 的序號為 w（在半關閉狀態(tài)炼幔，B 可能又發(fā)送了一些數(shù)據(jù)）。B 還必須重復上次已發(fā)送過的確認號 ack = u + 1史简。這時 B 就進入 LAST-ACK(最后確認)狀態(tài)乃秀，等待 A 的確認。
第四次揮手：A 在收到 B 的連接釋放報文后圆兵，必須對此發(fā)出確認跺讯。在確認報文段中把 ACK 置 1，確認號 ack = w + 1殉农，而自己的序號 seq = u + 1（前面發(fā)送的 FIN 報文段要消耗一個序號）刀脏。然后進入 TIME-WAIT(時間等待) 狀態(tài)。請注意超凳，現(xiàn)在 TCP 連接還沒有釋放掉愈污。必須經(jīng)過時間等待計時器設置的時間 2MSL（MSL：最長報文段壽命）后危队，A 才能進入到 CLOSED 狀態(tài)，然后撤銷傳輸控制塊钙畔，結束這次 TCP 連接。當然如果 B 一收到 A 的確認就進入 CLOSED 狀態(tài)金麸，然后撤銷傳輸控制塊擎析。所以在釋放連接時，B 結束 TCP 連接的時間要早于 A挥下。
10揍魂、為什么 TIME-WAIT 狀態(tài)必須等待 2MSL 的時間呢？
為了保證 A 發(fā)送的最后一個 ACK 報文段能夠到達 B棚瘟。這個 ACK 報文段有可能丟失现斋，因而使處在 LAST-ACK 狀態(tài)的 B 收不到對已發(fā)送的 FIN + ACK 報文段的確認。B 會超時重傳這個 FIN+ACK 報文段偎蘸，而 A 就能在 2MSL 時間內(nèi)（超時 + 1MSL 傳輸）收到這個重傳的 FIN+ACK 報文段庄蹋。接著 A 重傳一次確認，重新啟動 2MSL 計時器迷雪。最后限书，A 和 B 都正常進入到 CLOSED 狀態(tài)。如果 A 在 TIME-WAIT 狀態(tài)不等待一段時間章咧，而是在發(fā)送完 ACK 報文段后立即釋放連接倦西，那么就無法收到 B 重傳的 FIN + ACK 報文段，因而也不會再發(fā)送一次確認報文段赁严，這樣扰柠，B 就無法按照正常步驟進入 CLOSED 狀態(tài)。
防止已失效的連接請求報文段出現(xiàn)在本連接中疼约。A 在發(fā)送完最后一個 ACK 報文段后卤档，再經(jīng)過時間 2MSL，就可以使本連接持續(xù)的時間內(nèi)所產(chǎn)生的所有報文段都從網(wǎng)絡中消失忆谓。這樣就可以使下一個連接中不會出現(xiàn)這種舊的連接請求報文段裆装。
11、為什么第二次跟第三次不能合并, 第二次和第三次之間的等待是什么?
當服務器執(zhí)行第二次揮手之后, 此時證明客戶端不會再向服務端請求任何數(shù)據(jù), 但是服務端可能還正在給客戶端發(fā)送數(shù)據(jù)（可能是客戶端上一次請求的資源還沒有發(fā)送完畢）倡缠，所以此時服務端會等待把之前未傳輸完的數(shù)據(jù)傳輸完畢之后再發(fā)送關閉請求哨免。
12、标悸伲活計時器的作用琢唾？
除時間等待計時器外，TCP 還有一個倍芤活計時器（keepalive timer）采桃。設想這樣的場景：客戶已主動與服務器建立了 TCP 連接懒熙。但后來客戶端的主機突然發(fā)生故障。顯然普办，服務器以后就不能再收到客戶端發(fā)來的數(shù)據(jù)工扎。因此，應當有措施使服務器不要再白白等待下去衔蹲。這就需要使用敝铮活計時器了。
服務器每收到一次客戶的數(shù)據(jù)舆驶，就重新設置背鹘。活計時器，時間的設置通常是兩個小時沙廉。若兩個小時都沒有收到客戶端的數(shù)據(jù)拘荡，服務端就發(fā)送一個探測報文段，以后則每隔 75 秒鐘發(fā)送一次撬陵。若連續(xù)發(fā)送 10個 探測報文段后仍然無客戶端的響應珊皿，服務端就認為客戶端出了故障，接著就關閉這個連接巨税。
13亮隙、談談你對停止等待協(xié)議的理解？
停止等待協(xié)議是為了實現(xiàn)可靠傳輸?shù)墓讣校幕驹砭褪敲堪l(fā)完一個分組就停止發(fā)送溢吻，等待對方確認。在收到確認后再發(fā)下一個分組果元；在停止等待協(xié)議中促王，若接收方收到重復分組，就丟棄該分組而晒，但同時還要發(fā)送確認蝇狼。主要包括以下幾種情況：無差錯情況、出現(xiàn)差錯情況（超時重傳）倡怎、確認丟失和確認遲到迅耘、確認丟失和確認遲到。
14监署、談談你對 ARQ 協(xié)議的理解颤专？
自動重傳請求 ARQ 協(xié)議
停止等待協(xié)議中超時重傳是指只要超過一段時間仍然沒有收到確認，就重傳前面發(fā)送過的分組（認為剛才發(fā)送過的分組丟失了）钠乏。因此每發(fā)送完一個分組需要設置一個超時計時器栖秕，其重傳時間應比數(shù)據(jù)在分組傳輸?shù)钠骄禃r間更長一些。這種自動重傳方式常稱為自動重傳請求 ARQ晓避。
連續(xù) ARQ 協(xié)議
連續(xù) ARQ 協(xié)議可提高信道利用率簇捍。發(fā)送方維持一個發(fā)送窗口只壳，凡位于發(fā)送窗口內(nèi)的分組可以連續(xù)發(fā)送出去，而不需要等待對方確認暑塑。接收方一般采用累計確認吼句，對按序到達的最后一個分組發(fā)送確認，表明到這個分組為止的所有分組都已經(jīng)正確收到了事格。
15命辖、談談你對滑動窗口的了解？
TCP 利用滑動窗口實現(xiàn)流量控制的機制分蓖。滑動窗口（Sliding window）是一種流量控制技術尔许。早期的網(wǎng)絡通信中么鹤，通信雙方不會考慮網(wǎng)絡的擁擠情況直接發(fā)送數(shù)據(jù)。由于大家不知道網(wǎng)絡擁塞狀況味廊，同時發(fā)送數(shù)據(jù)蒸甜，導致中間節(jié)點阻塞掉包，誰也發(fā)不了數(shù)據(jù)余佛，所以就有了滑動窗口機制來解決此問題柠新。
TCP 中采用滑動窗口來進行傳輸控制，滑動窗口的大小意味著接收方還有多大的緩沖區(qū)可以用于接收數(shù)據(jù)辉巡。發(fā)送方可以通過滑動窗口的大小來確定應該發(fā)送多少字節(jié)的數(shù)據(jù)恨憎。當滑動窗口為 0 時，發(fā)送方一般不能再發(fā)送數(shù)據(jù)報郊楣，但有兩種情況除外憔恳，一種情況是可以發(fā)送緊急數(shù)據(jù)，例如净蚤，允許用戶終止在遠端機上的運行進程钥组。另一種情況是發(fā)送方可以發(fā)送一個 1 字節(jié)的數(shù)據(jù)報來通知接收方重新聲明它希望接收的下一字節(jié)及發(fā)送方的滑動窗口大小。
16今瀑、談下你對流量控制的理解程梦？
TCP 利用滑動窗口實現(xiàn)流量控制。流量控制是為了控制發(fā)送方發(fā)送速率，保證接收方來得及接收娱局。接收方發(fā)送的確認報文中的窗口字段可以用來控制發(fā)送方窗口大小碗殷，從而影響發(fā)送方的發(fā)送速率。將窗口字段設置為 0拿撩，則發(fā)送方不能發(fā)送數(shù)據(jù)。
17如蚜、談下你對 TCP 擁塞控制的理解压恒？使用了哪些算法影暴？
擁塞控制和流量控制不同，前者是一個全局性的過程探赫，而后者指點對點通信量的控制型宙。在某段時間，若對網(wǎng)絡中某一資源的需求超過了該資源所能提供的可用部分伦吠，網(wǎng)絡的性能就要變壞妆兑。這種情況就叫擁塞。
擁塞控制就是為了防止過多的數(shù)據(jù)注入到網(wǎng)絡中毛仪，這樣就可以使網(wǎng)絡中的路由器或鏈路不致于過載搁嗓。擁塞控制所要做的都有一個前提，就是網(wǎng)絡能夠承受現(xiàn)有的網(wǎng)絡負荷箱靴。擁塞控制是一個全局性的過程腺逛，涉及到所有的主機，所有的路由器衡怀，以及與降低網(wǎng)絡傳輸性能有關的所有因素棍矛。相反，流量控制往往是點對點通信量的控制抛杨，是個端到端的問題够委。流量控制所要做到的就是抑制發(fā)送端發(fā)送數(shù)據(jù)的速率，以便使接收端來得及接收怖现。
為了進行擁塞控制茁帽，TCP 發(fā)送方要維持一個擁塞窗口(cwnd) 的狀態(tài)變量。擁塞控制窗口的大小取決于網(wǎng)絡的擁塞程度屈嗤，并且動態(tài)變化脐雪。發(fā)送方讓自己的發(fā)送窗口取為擁塞窗口和接收方的接受窗口中較小的一個。
TCP 的擁塞控制采用了四種算法恢共，即：慢開始战秋、擁塞避免、快重傳和快恢復讨韭。在網(wǎng)絡層也可以使路由器采用適當?shù)姆纸M丟棄策略（如：主動隊列管理 AQM）脂信，以減少網(wǎng)絡擁塞的發(fā)生。
慢開始：
慢開始算法的思路是當主機開始發(fā)送數(shù)據(jù)時透硝，如果立即把大量數(shù)據(jù)字節(jié)注入到網(wǎng)絡狰闪，那么可能會引起網(wǎng)絡阻塞，因為現(xiàn)在還不知道網(wǎng)絡的符合情況濒生。經(jīng)驗表明埋泵，較好的方法是先探測一下，即由小到大逐漸增大發(fā)送窗口，也就是由小到大逐漸增大擁塞窗口數(shù)值丽声。cwnd 初始值為 1礁蔗，每經(jīng)過一個傳播輪次，cwnd 加倍雁社。
擁塞避免：
擁塞避免算法的思路是讓擁塞窗口 cwnd 緩慢增大浴井，即每經(jīng)過一個往返時間 RTT 就把發(fā)送方的 cwnd 加 1。
快重傳與快恢復：
在 TCP/IP 中霉撵，快速重傳和快恢復（fast retransmit and recovery磺浙，F(xiàn)RR）是一種擁塞控制算法，它能快速恢復丟失的數(shù)據(jù)包徒坡。
沒有 FRR撕氧，如果數(shù)據(jù)包丟失了，TCP 將會使用定時器來要求傳輸暫停喇完。在暫停的這段時間內(nèi)伦泥，沒有新的或復制的數(shù)據(jù)包被發(fā)送。有了 FRR何暮，如果接收機接收到一個不按順序的數(shù)據(jù)段，它會立即給發(fā)送機發(fā)送一個重復確認铐殃。如果發(fā)送機接收到三個重復確認海洼，它會假定確認件指出的數(shù)據(jù)段丟失了，并立即重傳這些丟失的數(shù)據(jù)段富腊。
有了 FRR坏逢，就不會因為重傳時要求的暫停被耽誤。當有單獨的數(shù)據(jù)包丟失時赘被，快速重傳和快恢復（FRR）能最有效地工作是整。當有多個數(shù)據(jù)信息包在某一段很短的時間內(nèi)丟失時，它則不能很有效地工作民假。
18浮入、什么是粘包？
在進行 Java NIO 學習時羊异，可能會發(fā)現(xiàn)：如果客戶端連續(xù)不斷的向服務端發(fā)送數(shù)據(jù)包時事秀，服務端接收的數(shù)據(jù)會出現(xiàn)兩個數(shù)據(jù)包粘在一起的情況。
TCP 是基于字節(jié)流的野舶，雖然應用層和 TCP 傳輸層之間的數(shù)據(jù)交互是大小不等的數(shù)據(jù)塊易迹，但是 TCP 把這些數(shù)據(jù)塊僅僅看成一連串無結構的字節(jié)流，沒有邊界平道；
從 TCP 的幀結構也可以看出睹欲，在 TCP 的首部沒有表示數(shù)據(jù)長度的字段。
基于上面兩點，在使用 TCP 傳輸數(shù)據(jù)時窘疮，才有粘包或者拆包現(xiàn)象發(fā)生的可能袋哼。一個數(shù)據(jù)包中包含了發(fā)送端發(fā)送的兩個數(shù)據(jù)包的信息，這種現(xiàn)象即為粘包考余。
接收端收到了兩個數(shù)據(jù)包先嬉，但是這兩個數(shù)據(jù)包要么是不完整的，要么就是多出來一塊楚堤，這種情況即發(fā)生了拆包和粘包疫蔓。拆包和粘包的問題導致接收端在處理的時候會非常困難，因為無法區(qū)分一個完整的數(shù)據(jù)包身冬。
19衅胀、TCP 黏包是怎么產(chǎn)生的？
發(fā)送方產(chǎn)生粘包
采用 TCP 協(xié)議傳輸數(shù)據(jù)的客戶端與服務器經(jīng)常是保持一個長連接的狀態(tài)（一次連接發(fā)一次數(shù)據(jù)不存在粘包）酥筝，雙方在連接不斷開的情況下滚躯，可以一直傳輸數(shù)據(jù)。但當發(fā)送的數(shù)據(jù)包過于的小時嘿歌，那么 TCP 協(xié)議默認的會啟用 Nagle 算法掸掏，將這些較小的數(shù)據(jù)包進行合并發(fā)送（緩沖區(qū)數(shù)據(jù)發(fā)送是一個堆壓的過程）；這個合并過程就是在發(fā)送緩沖區(qū)中進行的宙帝，也就是說數(shù)據(jù)發(fā)送出來它已經(jīng)是粘包的狀態(tài)了丧凤。
接收方產(chǎn)生粘包
接收方采用 TCP 協(xié)議接收數(shù)據(jù)時的過程是這樣的：數(shù)據(jù)到接收方，從網(wǎng)絡模型的下方傳遞至傳輸層步脓，傳輸層的 TCP 協(xié)議處理是將其放置接收緩沖區(qū)愿待，然后由應用層來主動獲取（C 語言用 recv靴患、read 等函數(shù)）仍侥；這時會出現(xiàn)一個問題，就是我們在程序中調用的讀取數(shù)據(jù)函數(shù)不能及時的把緩沖區(qū)中的數(shù)據(jù)拿出來鸳君，而下一個數(shù)據(jù)又到來并有一部分放入的緩沖區(qū)末尾农渊，等我們讀取數(shù)據(jù)時就是一個粘包。（放數(shù)據(jù)的速度 > 應用層拿數(shù)據(jù)速度）
20或颊、怎么解決拆包和粘包腿时？
分包機制一般有兩個通用的解決方法：
特殊字符控制；
在包頭首都添加數(shù)據(jù)包的長度饭宾。
如果使用 netty 的話批糟，就有專門的編碼器和解碼器解決拆包和粘包問題了。
tips：UDP 沒有粘包問題看铆，但是有丟包和亂序徽鼎。不完整的包是不會有的，收到的都是完全正確的包。傳送的數(shù)據(jù)單位協(xié)議是 UDP 報文或用戶數(shù)據(jù)報否淤，發(fā)送的時候既不合并悄但，也不拆分。
21石抡、你對 HTTP 狀態(tài)碼有了解嗎檐嚣？
1XX 信息
- 100 Continue ：表明到目前為止都很正常，客戶端可以繼續(xù)發(fā)送請求或者忽略這個響應啰扛。
2XX 成功
200 OK
204 No Content ：請求已經(jīng)成功處理嚎京，但是返回的響應報文不包含實體的主體部分。一般在只需要從客戶端往服務器發(fā)送信息隐解，而不需要返回數(shù)據(jù)時使用鞍帝。
206 Partial Content ：表示客戶端進行了范圍請求，響應報文包含由 Content-Range 指定范圍的實體內(nèi)容煞茫。
3XX 重定向
301 Moved Permanently ：永久性重定向帕涌；
302 Found ：臨時性重定向；
303 See Other ：和 302 有著相同的功能续徽，但是 303 明確要求客戶端應該采用 GET 方法獲取資源蚓曼。
304 Not Modified ：如果請求報文首部包含一些條件，例如：If-Match钦扭，If-Modified-Since纫版，If-None-Match，If-Range土全，If-Unmodified-Since捎琐，如果不滿足條件会涎，則服務器會返回 304 狀態(tài)碼裹匙。
307 Temporary Redirect ：臨時重定向，與 302 的含義類似末秃，但是 307 要求瀏覽器不會把重定向請求的 POST 方法改成 GET 方法概页。
4XX 客戶端錯誤
400 Bad Request ：請求報文中存在語法錯誤。
401 Unauthorized ：該狀態(tài)碼表示發(fā)送的請求需要有認證信息（BASIC 認證练慕、DIGEST 認證）惰匙。如果之前已進行過一次請求，則表示用戶認證失敗铃将。
403 Forbidden ：請求被拒絕项鬼。
404 Not Found
5XX 服務器錯誤
500 Internal Server Error ：服務器正在執(zhí)行請求時發(fā)生錯誤；
503 Service Unavailable ：服務器暫時處于超負載或正在進行停機維護劲阎，現(xiàn)在無法處理請求绘盟。
22、HTTP 狀態(tài)碼 301 和 302 代表的是什么？有什么區(qū)別龄毡？
301吠卷，302 都是 HTTP 狀態(tài)的編碼，都代表著某個 URL 發(fā)生了轉移沦零。
區(qū)別：
301 redirect: 301 代表永久性轉移（Permanently Moved）
302 redirect: 302 代表暫時性轉移（Temporarily Moved）
23祭隔、forward 和 redirect 的區(qū)別？
Forward 和 Redirect 代表了兩種請求轉發(fā)方式：直接轉發(fā)和間接轉發(fā)路操。
直接轉發(fā)方式（Forward）：客戶端和瀏覽器只發(fā)出一次請求疾渴，Servlet、HTML寻拂、JSP 或其它信息資源程奠，由第二個信息資源響應該請求，在請求對象 request 中祭钉，保存的對象對于每個信息資源是共享的瞄沙。
間接轉發(fā)方式（Redirect）：實際是兩次 HTTP 請求，服務器端在響應第一次請求的時候慌核，讓瀏覽器再向另外一個 URL 發(fā)出請求距境，從而達到轉發(fā)的目的。
舉個通俗的例子：
直接轉發(fā)就相當于：“A 找 B 借錢垮卓，B 說沒有垫桂，B 去找 C 借，借到借不到都會把消息傳遞給 A”粟按；
間接轉發(fā)就相當于："A 找 B 借錢诬滩，B 說沒有，讓 A 去找 C 借"灭将。
24疼鸟、HTTP 方法有哪些？
客戶端發(fā)送的 請求報文 第一行為請求行庙曙，包含了方法字段空镜。
GET：獲取資源，當前網(wǎng)絡中絕大部分使用的都是 GET捌朴；
HEAD：獲取報文首部吴攒，和 GET 方法類似，但是不返回報文實體主體部分砂蔽；
POST：傳輸實體主體
PUT：上傳文件洼怔，由于自身不帶驗證機制，任何人都可以上傳文件左驾，因此存在安全性問題镣隶，一般不使用該方法泽台。
PATCH：對資源進行部分修改。PUT 也可以用于修改資源矾缓，但是只能完全替代原始資源怀酷，PATCH 允許部分修改。
OPTIONS：查詢指定的 URL 支持的方法嗜闻；
CONNECT：要求在與代理服務器通信時建立隧道蜕依。使用 SSL（Secure Sockets Layer，安全套接層）和 TLS（Transport Layer Security琉雳，傳輸層安全）協(xié)議把通信內(nèi)容加密后經(jīng)網(wǎng)絡隧道傳輸样眠。
TRACE：追蹤路徑。服務器會將通信路徑返回給客戶端翠肘。發(fā)送請求時檐束，在 Max-Forwards 首部字段中填入數(shù)值，每經(jīng)過一個服務器就會減 1束倍，當數(shù)值為 0 時就停止傳輸被丧。通常不會使用 TRACE，并且它容易受到 XST 攻擊（Cross-Site Tracing绪妹，跨站追蹤）甥桂。
26、說下 GET 和 POST 的區(qū)別邮旷？
GET 和 POST 本質都是 HTTP 請求黄选，只不過對它們的作用做了界定和適配，并且讓他們適應各自的場景婶肩。
本質區(qū)別：GET 只是一次 HTTP請求办陷，POST 先發(fā)請求頭再發(fā)請求體，實際上是兩次請求民镜。
從功能上講植旧，GET 一般用來從服務器上獲取資源，POST 一般用來更新服務器上的資源嵌戈；
從 REST 服務角度上說尉姨，GET 是冪等的，即讀取同一個資源，總是得到相同的數(shù)據(jù)，而 POST 不是冪等的，因為每次請求對資源的改變并不是相同的；進一步地，GET 不會改變服務器上的資源项滑，而 POST 會對服務器資源進行改變；
從請求參數(shù)形式上看严蓖，GET 請求的數(shù)據(jù)會附在 URL 之后毫深，即將請求數(shù)據(jù)放置在 HTTP 報文的 請求頭 中，以 ? 分割 URL 和傳輸數(shù)據(jù)，參數(shù)之間以 & 相連巡球。特別地酣栈，如果數(shù)據(jù)是英文字母/數(shù)字窖维，原樣發(fā)送琳轿；否則媚送，會將其編碼為 application/x-www-form-urlencoded MIME 字符串(如果是空格中燥，轉換為+寇甸，如果是中文/其他字符塘偎，則直接把字符串用 BASE64 加密疗涉，得出如：%E4%BD%A0%E5%A5%BD，其中 ％XX 中的 XX 為該符號以 16 進制表示的 ASCII)吟秩；而 POST 請求會把提交的數(shù)據(jù)則放置在是 HTTP 請求報文的 請求體 中咱扣；
就安全性而言，POST 的安全性要比 GET 的安全性高涵防，因為 GET 請求提交的數(shù)據(jù)將明文出現(xiàn)在 URL 上闹伪，而且 POST 請求參數(shù)則被包裝到請求體中，相對更安全壮池；
從請求的大小看偏瓤，GET 請求的長度受限于瀏覽器或服務器對 URL 長度的限制，允許發(fā)送的數(shù)據(jù)量比較小椰憋，而 POST 請求則是沒有大小限制的厅克。
27、DNS 的解析過程橙依？
主機向本地域名服務器的查詢一般都是采用遞歸查詢证舟。所謂遞歸查詢就是：如果主機所詢問的本地域名服務器不知道被查詢的域名的 IP 地址，那么本地域名服務器就以 DNS 客戶的身份窗骑，向根域名服務器繼續(xù)發(fā)出查詢請求報文(即替主機繼續(xù)查詢)女责，而不是讓主機自己進行下一步查詢。因此创译，遞歸查詢返回的查詢結果或者是所要查詢的 IP 地址抵知，或者是報錯，表示無法查詢到所需的 IP 地址软族。
本地域名服務器向根域名服務器的查詢的迭代查詢辛藻。迭代查詢的特點：當根域名服務器收到本地域名服務器發(fā)出的迭代查詢請求報文時，要么給出所要查詢的 IP 地址互订，要么告訴本地服務器：“你下一步應當向哪一個域名服務器進行查詢”吱肌。然后讓本地服務器進行后續(xù)的查詢。根域名服務器通常是把自己知道的頂級域名服務器的 IP 地址告訴本地域名服務器仰禽，讓本地域名服務器再向頂級域名服務器查詢氮墨。頂級域名服務器在收到本地域名服務器的查詢請求后，要么給出所要查詢的 IP 地址吐葵，要么告訴本地服務器下一步應當向哪一個權限域名服務器進行查詢规揪。最后，本地域名服務器得到了所要解析的 IP 地址或報錯温峭，然后把這個結果返回給發(fā)起查詢的主機猛铅。
28、談談你對域名緩存的了解凤藏？
為了提高 DNS 查詢效率奸忽，并減輕服務器的負荷和減少因特網(wǎng)上的 DNS 查詢報文數(shù)量堕伪，在域名服務器中廣泛使用了高速緩存，用來存放最近查詢過的域名以及從何處獲得域名映射信息的記錄栗菜。
由于名字到地址的綁定并不經(jīng)常改變欠雌，為保持高速緩存中的內(nèi)容正確，域名服務器應為每項內(nèi)容設置計時器并處理超過合理時間的項（例如：每個項目兩天）疙筹。當域名服務器已從緩存中刪去某項信息后又被請求查詢該項信息富俄，就必須重新到授權管理該項的域名服務器綁定信息。當權限服務器回答一個查詢請求時而咆，在響應中都指明綁定有效存在的時間值霍比。增加此時間值可減少網(wǎng)絡開銷，而減少此時間值可提高域名解析的正確性暴备。
不僅在本地域名服務器中需要高速緩存桂塞，在主機中也需要。許多主機在啟動時從本地服務器下載名字和地址的全部數(shù)據(jù)庫馍驯，維護存放自己最近使用的域名的高速緩存阁危，并且只在從緩存中找不到名字時才使用域名服務器。維護本地域名服務器數(shù)據(jù)庫的主機應當定期地檢查域名服務器以獲取新的映射信息汰瘫，而且主機必須從緩存中刪除無效的項狂打。由于域名改動并不頻繁，大多數(shù)網(wǎng)點不需花精力就能維護數(shù)據(jù)庫的一致性混弥。
29趴乡、談下你對 HTTP 長連接和短連接的理解？分別應用于哪些場景蝗拿？
在 HTTP/1.0 中默認使用短連接晾捏。也就是說，客戶端和服務器每進行一次 HTTP 操作哀托，就建立一次連接惦辛，任務結束就中斷連接。當客戶端瀏覽器訪問的某個 HTML 或其他類型的 Web 頁中包含有其他的 Web 資源（如：JavaScript 文件仓手、圖像文件胖齐、CSS 文件等），每遇到這樣一個 Web 資源嗽冒，瀏覽器就會重新建立一個 HTTP 會話呀伙。
而從 HTTP/1.1 起，默認使用長連接添坊，用以保持連接特性剿另。使用長連接的 HTTP 協(xié)議，會在響應頭加入這行代碼
Connection:keep-alive
在使用長連接的情況下，當一個網(wǎng)頁打開完成后雨女，客戶端和服務器之間用于傳輸 HTTP 數(shù)據(jù)的 TCP 連接不會關閉谚攒，客戶端再次訪問這個服務器時，會繼續(xù)使用這一條已經(jīng)建立的連接戚篙。
Keep-Alive 不會永久保持連接五鲫，它有一個保持時間溺职，可以在不同的服務器軟件（如：Apache）中設定這個時間岔擂。實現(xiàn)長連接需要客戶端和服務端都支持長連接。
30浪耘、談下 HTTP 1.0 和 1.1乱灵、1.2 的主要變化？
HTTP1.1 的主要變化：
HTTP1.0 經(jīng)過多年發(fā)展七冲，在 1.1 提出了改進痛倚。首先是提出了長連接，HTTP 可以在一次 TCP 連接中不斷發(fā)送請求澜躺。
然后 HTTP1.1 支持只發(fā)送 header 而不發(fā)送 body蝉稳。原因是先用 header 判斷能否成功，再發(fā)數(shù)據(jù)掘鄙，節(jié)約帶寬耘戚，事實上，post 請求默認就是這樣做的操漠。
HTTP1.1 的 host 字段收津。由于虛擬主機可以支持多個域名，所以一般將域名解析后得到 host浊伙。
HTTP2.0 的主要變化：
HTTP2.0 支持多路復用撞秋，同一個連接可以并發(fā)處理多個請求，方法是把 HTTP數(shù)據(jù)包拆為多個幀嚣鄙，并發(fā)有序的發(fā)送吻贿，根據(jù)序號在另一端進行重組，而不需要一個個 HTTP請求順序到達哑子；
HTTP2.0 支持服務端推送廓八，就是服務端在 HTTP 請求到達后，除了返回數(shù)據(jù)之外赵抢，還推送了額外的內(nèi)容給客戶端剧蹂；
HTTP2.0 壓縮了請求頭，同時基本單位是二進制幀流烦却，這樣的數(shù)據(jù)占用空間更少宠叼；
HTTP2.0 適用于 HTTPS 場景，因為其在 HTTP和 TCP 中間加了一層 SSL 層。
31冒冬、HTTPS 的工作過程伸蚯？
客戶端發(fā)送自己支持的加密規(guī)則給服務器，代表告訴服務器要進行連接了简烤；
服務器從中選出一套加密算法和 hash 算法以及自己的身份信息（地址等）以證書的形式發(fā)送給瀏覽器剂邮，證書中包含服務器信息，加密公鑰横侦，證書的辦法機構挥萌；
客戶端收到網(wǎng)站的證書之后要做下面的事情：
3.1 驗證證書的合法性；
3.2 果驗證通過證書枉侧，瀏覽器會生成一串隨機數(shù)引瀑，并用證書中的公鑰進行加密；
3.3 用約定好的 hash 算法計算握手消息榨馁，然后用生成的密鑰進行加密憨栽，然后一起發(fā)送給服務器。
- 服務器接收到客戶端傳送來的信息翼虫，要做下面的事情：
4.1 用私鑰解析出密碼屑柔，用密碼解析握手消息，驗證 hash 值是否和瀏覽器發(fā)來的一致珍剑；
4.2 使用密鑰加密消息掸宛；
- 如果計算法 hash 值一致，握手成功次慢。
32旁涤、HTTP 和 HTTPS 的區(qū)別？
開銷：HTTPS 協(xié)議需要到 CA 申請證書迫像，一般免費證書很少劈愚，需要交費；
資源消耗：HTTP 是超文本傳輸協(xié)議闻妓，信息是明文傳輸菌羽，HTTPS 則是具有安全性的 ssl 加密傳輸協(xié)議，需要消耗更多的 CPU 和內(nèi)存資源由缆；
端口不同：HTTP 和 HTTPS 使用的是完全不同的連接方式注祖，用的端口也不一樣，前者是 80均唉，后者是 443是晨；
安全性：HTTP 的連接很簡單，是無狀態(tài)的舔箭；HTTPS 協(xié)議是由 TSL+HTTP 協(xié)議構建的可進行加密傳輸罩缴、身份認證的網(wǎng)絡協(xié)議蚊逢，比 HTTP 協(xié)議安全。
33箫章、HTTPS 的優(yōu)缺點烙荷？
優(yōu)點：
使用 HTTPS 協(xié)議可認證用戶和服務器，確保數(shù)據(jù)發(fā)送到正確的客戶機和服務器檬寂；
HTTPS 協(xié)議是由 SSL + HTTP 協(xié)議構建的可進行加密傳輸终抽、身份認證的網(wǎng)絡協(xié)議，要比 HTTP 協(xié)議安全桶至，可防止數(shù)據(jù)在傳輸過程中不被竊取昼伴、改變，確保數(shù)據(jù)的完整性塞茅；
HTTPS 是現(xiàn)行架構下最安全的解決方案亩码，雖然不是絕對安全季率，但它大幅增加了中間人攻擊的成本野瘦。
缺點：
HTTPS 協(xié)議握手階段比較費時，會使頁面的加載時間延長近 50%飒泻，增加 10% 到 20% 的耗電鞭光；
HTTPS 連接緩存不如 HTTP 高效，會增加數(shù)據(jù)開銷和功耗泞遗，甚至已有的安全措施也會因此而受到影響惰许；
SSL 證書需要錢，功能越強大的證書費用越高史辙，個人網(wǎng)站汹买、小網(wǎng)站沒有必要一般不會用；
SSL 證書通常需要綁定 IP聊倔，不能在同一 IP 上綁定多個域名晦毙，IPv4 資源不可能支撐這個消耗；
HTTPS 協(xié)議的加密范圍也比較有限耙蔑，在黑客攻擊见妒、拒絕服務攻擊、服務器劫持等方面幾乎起不到什么作用甸陌。最關鍵的须揣，SSL 證書的信用鏈體系并不安全，特別是在某些國家可以控制 CA 根證書的情況下钱豁，中間人攻擊一樣可行耻卡。
34、什么是數(shù)字簽名牲尺？
為了避免數(shù)據(jù)在傳輸過程中被替換卵酪，比如黑客修改了你的報文內(nèi)容，但是你并不知道，所以我們讓發(fā)送端做一個數(shù)字簽名凛澎，把數(shù)據(jù)的摘要消息進行一個加密霹肝，比如 MD5，得到一個簽名塑煎，和數(shù)據(jù)一起發(fā)送沫换。然后接收端把數(shù)據(jù)摘要進行 MD5 加密，如果和簽名一樣最铁，則說明數(shù)據(jù)確實是真的讯赏。
35、什么是數(shù)字證書冷尉？
對稱加密中漱挎，雙方使用公鑰進行解密。雖然數(shù)字簽名可以保證數(shù)據(jù)不被替換雀哨，但是數(shù)據(jù)是由公鑰加密的磕谅，如果公鑰也被替換，則仍然可以偽造數(shù)據(jù)雾棺，因為用戶不知道對方提供的公鑰其實是假的膊夹。所以為了保證發(fā)送方的公鑰是真的，CA 證書機構會負責頒發(fā)一個證書捌浩，里面的公鑰保證是真的放刨，用戶請求服務器時，服務器將證書發(fā)給用戶，這個證書是經(jīng)由系統(tǒng)內(nèi)置證書的備案的。
36坡锡、什么是對稱加密和非對稱加密？
對稱密鑰加密是指加密和解密使用同一個密鑰的方式螟碎，這種方式存在的最大問題就是密鑰發(fā)送問題，即如何安全地將密鑰發(fā)給對方馋辈。
非對稱加密指使用一對非對稱密鑰抚芦，即：公鑰和私鑰，公鑰可以隨意發(fā)布迈螟，但私鑰只有自己知道叉抡。發(fā)送密文的一方使用對方的公鑰進行加密處理，對方接收到加密信息后答毫，使用自己的私鑰進行解密褥民。
由于非對稱加密的方式不需要發(fā)送用來解密的私鑰，所以可以保證安全性洗搂。但是和對稱加密比起來消返，它非常的慢载弄，所以我們還是要用對稱加密來傳送消息，但對稱加密所使用的密鑰我們可以通過非對稱加密的方式發(fā)送出去撵颊。
37.進程和線程之間通信的區(qū)別宇攻？
進程的通信一般通過操作系統(tǒng)的公共區(qū)進行。
線程之間的數(shù)據(jù)可以直接提供給其他線程使用倡勇，不必通過操作系統(tǒng)
- 進程間的通信：管道逞刷，消息隊列，信號量妻熊，共享內(nèi)存夸浅，套接字
- 線程間的通信：信號量，鎖機制
線程之間的通信主要用于線程同步扔役，所以沒有進程中的用于數(shù)據(jù)交換的通信機制帆喇。
38. 導致粘包問題？
導致粘包問題的原因亿胸，可能來自發(fā)送方坯钦，也可能來自接受方。
- 發(fā)送方损敷，TCP默認使用 nagle 算法葫笼，會收集多個小分組進行一起發(fā)送深啤。
- 接收方拗馒，接收方應用層的讀取速度小于TCP接受數(shù)據(jù)包的速度
什么時候需要處理粘包現(xiàn)象？
如果發(fā)送方發(fā)送的同一塊數(shù)據(jù)不用處理粘包溯街，但是如果是不同數(shù)據(jù)格式不同組數(shù)據(jù)诱桂，就需要處理粘包。
處理辦法呈昔？
- 發(fā)送方挥等，發(fā)送方關閉 nagle 合并算法。
- 應用層堤尾，1肝劲， 每條數(shù)據(jù)有固定的格式，開始符郭宝，結束符2.發(fā)送每條數(shù)據(jù)將數(shù)據(jù)長度一并發(fā)送辞槐。
為什么UDP不會產(chǎn)生粘包？
UDP則是面向消息傳輸?shù)恼呈遥且詳?shù)據(jù)包的形式發(fā)送榄檬，是有保護消息邊界的，接收方一次只接受一條獨立的信息衔统，所以不存在粘包問題鹿榜。
有三個數(shù)據(jù)包海雪，大小分別為2k、4k舱殿、6k奥裸，如果采用UDP發(fā)送的話，不管接受方的接收緩存有多大沪袭，我們必須要進行至少三次以上的發(fā)送才能把數(shù)據(jù)包發(fā)送完刺彩，但是使用TCP協(xié)議發(fā)送的話，我們只需要接受方的接收緩存有12k的大小枝恋，就可以一次把這3個數(shù)據(jù)包全部發(fā)送完畢创倔。
39. IP協(xié)議的特點
IP 協(xié)議是一種無連接不可靠的分組傳送協(xié)議
IP 是一種點對點的協(xié)議， 主機對主機焚碌，路由對路由
ICMP 利用網(wǎng)絡上機器IP地址的唯一性畦攘，給目標IP地址發(fā)送一個數(shù)據(jù)包，再要求對方返回一個同樣大小的數(shù)據(jù)包來確定兩臺網(wǎng)絡機器是否連接相通十电，時延是多少知押。
40. SYN 攻擊
Syn攻擊就是 攻擊客戶端
在短時間內(nèi)偽造大量不存在的IP地址，向服務器不斷地發(fā)送syn包鹃骂，服務器回復確認包台盯，并等待客戶的確認，由于源地址是不存在的畏线，服務器需要不斷的重發(fā)直
至超時静盅，這些偽造的SYN包將長時間占用未連接隊列，正常的SYN請求被丟棄寝殴，目標系統(tǒng)運行緩慢蒿叠，嚴重者引起網(wǎng)絡堵塞甚至系統(tǒng)癱瘓。
netstat -n -p TCP | grep SYN_RECV
41. DDos攻擊
一般來說是指攻擊者利用“肉雞”對目標網(wǎng)站在較短的時間內(nèi)發(fā)起大量請求蚣常，大規(guī)模消耗目標網(wǎng)站的主機資源市咽，讓它無法正常服務。
防范措施抵蚊， 1. 黑名單施绎， 2.DDos 清洗，3.CDN加速
