簡介

HTTP協(xié)議(超文本傳輸協(xié)議)和 UDP(用戶數(shù)據(jù)包協(xié)議)，TCP 協(xié)議(傳輸控制協(xié)議)

TCP/IP是個協(xié)議組，可分為四個層次：網(wǎng)絡(luò)接口層、網(wǎng)絡(luò)層、傳輸層和應(yīng)用層。

在網(wǎng)絡(luò)層有IP協(xié)議、ICMP協(xié)議、ARP協(xié)議、RARP協(xié)議和BOOTP協(xié)議。

在傳輸層中有TCP協(xié)議與UDP協(xié)議，arq協(xié)議。

在應(yīng)用層有FTP、HTTP、TELNET、SMTP、DNS等協(xié)議。

TCP 與 UDP

TCP與UDP基本區(qū)別

UDP與TCP的區(qū)別與聯(lián)系

一：UDP是面向無連接的協(xié)議，TCP 是面向連接的協(xié)議

UDP發(fā)出請求后，即發(fā)送數(shù)據(jù)之前不需要先連接，TCP 發(fā)送數(shù)據(jù)之前需要先連接

二：UDP 相對TCP來說是不可靠的

因為 UDP 在發(fā)送數(shù)據(jù)以后，沒有采用超時重發(fā)，停止等待機制，擁塞控制

三：TCP 面向流，UDP 面向報文

TCP優(yōu)缺點：

優(yōu)點：可靠，穩(wěn)定

TCP的可靠體現(xiàn)在TCP在傳遞數(shù)據(jù)之前，會有三次握手來建立連接，而且在數(shù)據(jù)傳遞時，有確認、窗口、重傳、擁塞控制機制，在數(shù)據(jù)傳完后，還會斷開連接用來節(jié)約系統(tǒng)資源。

缺點：

慢，效率低，占用系統(tǒng)資源高，易被攻擊

TCP在傳遞數(shù)據(jù)之前，要先建連接，這會消耗時間，而且在數(shù)據(jù)傳遞時，確認機制、重傳機制、擁塞控制機制等都會消耗大量的時間，而且要在每臺設(shè)備上維護所有的傳輸連接，事實上，每個連接都會占用系統(tǒng)的CPU、內(nèi)存等硬件資源。

而且，因為TCP有確認機制、三次握手機制，這些也導致TCP容易被人利用，實現(xiàn)DOS、DDOS、CC等攻擊。

UDP優(yōu)缺點：

優(yōu)點：

快，比TCP稍安全

UDP沒有TCP的握手、確認、窗口、重傳、擁塞控制等機制，UDP是一個無狀態(tài)的傳輸協(xié)議，所以它在傳遞數(shù)據(jù)時非常快。沒有TCP的這些機制，UDP較TCP被攻擊者利用的漏洞就要少一些。但UDP也是無法避免攻擊的，比如：UDP Flood攻擊……

缺點：

不可靠，不穩(wěn)定 。因為UDP沒有TCP那些可靠的機制，在數(shù)據(jù)傳遞時，如果網(wǎng)絡(luò)質(zhì)量不好，就會很容易丟包。

### 三次握手與四次揮手

三次握手

第一次握手:第一次連接時，客戶端向服務(wù)器端發(fā)送SYN(syn=j)，等待服務(wù)器端的確認，此時客戶端進入SYN_SEND狀態(tài)，SYN：同步序列號

第二次握手：服務(wù)器端收到客戶端發(fā)來的SYN，必須向客戶端發(fā)送ACK包(ack=j+1=k)，同時自己必須發(fā)送一個SYN包，即syn+ack，此時進入SYN_REC狀態(tài)

第三次握手：客戶端收到服務(wù)器端發(fā)來的syn+ack包，向服務(wù)器發(fā)送ack包(ack=k+1),發(fā)送完畢，此時進入ESTABLISH狀態(tài)，連接成功，完成第三次連接。

發(fā)送 確認

第一次：SYN=1 SEQ=X ACK=0(客)

第二次：SYN=1 SEQ=Y ACK=X+1(服)

第三次： SEQ=X+1 ACK=Y+1(客)

4次揮手

當主機A完成數(shù)據(jù)傳輸后,將控制位FIN置1,提出停止TCP連接的請求

A進入終止等待1(FIN-WAIT-1)狀態(tài)

主機B收到FIN后對其作出響應(yīng),確認這一方向上的TCP連接將關(guān)閉,將ACK置1

tcp處于半關(guān)閉狀態(tài)(half-close)

a收到b端的確認后，就進入終止等待2狀態(tài)

由B 端再提出反方向的關(guān)閉請求,將FIN置1

進入last-wait狀態(tài)

主機A對主機B的請求進行確認,將ACK置1,雙方向的關(guān)閉結(jié)束.

進入時間等待狀態(tài)(time-wait)

時間等待計數(shù)器設(shè)置的時間過了2msl以后，進入closed狀態(tài)

三次握手的原因

如果只有兩次握手的話，比如說失效的報文段，突然發(fā)送到服務(wù)端，服務(wù)端收到失效報文段的請求后，會發(fā)送確認報文，新的連接就建立起來了。但現(xiàn)在由于客戶端并沒有發(fā)出請求，所以并不會理睬服務(wù)端的確認，也不會像服務(wù)端發(fā)送數(shù)據(jù)。而服務(wù)端以為已經(jīng)連接起來了，一直在等待，浪費資源。

四次揮手的原因

TCP建立連接要進行3次握手,而斷開連接要進行4次,這是由于TCP的半關(guān)閉造成的,因為TCP連接是全雙工的(

即數(shù)據(jù)可在兩個方向上同時傳遞)所以進行關(guān)閉時每個方向上都要單獨進行關(guān)閉,這個單方向的關(guān)閉就叫半關(guān)閉.

關(guān)閉的方法是一方完成它的數(shù)據(jù)傳輸后,就發(fā)送一個FIN來向另一方通告將要終止這個方向的連接.當一端收到一個FIN,它必須

通知應(yīng)用層TCP連接已終止了這個方向的數(shù)據(jù)傳送,發(fā)送FIN通常是應(yīng)用層進行關(guān)閉的結(jié)果.

名詞解釋

ACK TCP報頭的控制位之一,對數(shù)據(jù)進行確認.確認由目的端發(fā)出,用它來告訴發(fā)送端這個序列號之前的數(shù)據(jù)段

都收到了.比如,確認號為X,則表示前X-1個數(shù)據(jù)段都收到了,只有當ACK=1時,確認號才有效,當ACK=0時,確認號無效,這時會要求重傳數(shù)據(jù),保證數(shù)據(jù)的完整性.

SYN 同步序列號,TCP建立連接時將這個位置1

FIN 發(fā)送端完成發(fā)送任務(wù)位,當TCP完成數(shù)據(jù)傳輸需要斷開時,提出斷開連接的一方將這位置1

Http 與 https

Http 是在應(yīng)用層上的傳輸協(xié)議，底層是 TCP 協(xié)議實現(xiàn)的，

它一種面向無狀態(tài)的連接，短連接，

之所以說他無狀態(tài)，是因為在每一次請求完成之后，都會把連接關(guān)了，不會記住是哪一個客戶端連接。

四種請求方式

get，post，pull，delete

請求信息有請求行，請求頭，請求正文

請求行：請求方式，請求地址，請求協(xié)議

請求頭：頭名稱，頭值

請求正文：(只有post請求才會有)

響應(yīng)信息有相應(yīng)行，響應(yīng)頭，響應(yīng)正文

響應(yīng)行：響應(yīng)協(xié)議，狀態(tài)碼，狀態(tài)信息

響應(yīng) 頭：頭名稱和頭值

響應(yīng)正文

Http1.0與Http1.1，Http2.0的區(qū)別

http 2.0采用二進制的格式傳送數(shù)據(jù)，不再使用文本格式傳送數(shù)據(jù)

http2.0對消息頭采用hpack壓縮算法，http1.x的版本消息頭帶有大量的冗余消息

http2.0 采用多路復用，即用一個tcp連接處理所有的請求，真正意義上做到了并發(fā)請求，流還支持優(yōu)先級和流量控制

http2.0支持server push，服務(wù)端可以主動把css，jsp文件主動推送到客戶端，不需要客戶端解析HTML，再發(fā)送請求，當客戶端需要的時候，它已經(jīng)在客戶端了。

Http1.0一次只能處理一個請求和響應(yīng)，Http1.1一次能處理多個請求和響應(yīng)

多個請求和響應(yīng)過程可以重疊

增加了更多的請求頭和響應(yīng)頭，比如Host、If-Unmodified-Since請求頭等

http和https的區(qū)別

https相當于http加上安全套接字，采用ssl加密技術(shù)

主要的區(qū)別

在osi模型中，http工作于應(yīng)用層，https工作與傳輸層

http傳輸?shù)臅r候采用明文傳輸，https采用加密傳輸

http不需要證書，https需要響應(yīng)額證書

http以http開頭，默認端口是80，https 以https開頭，默認的端口是243

上傳視頻的時候為什么不用 Http 協(xié)議？

因為上傳視頻的時候文件一般比較長，如果我們采用 post 請求的話，寫到輸出流中，它并不會直接寫到服務(wù)器中，而是會緩存在內(nèi)存中，會影響我們的執(zhí)行效率

擴展補充

停止等待機制：是指每發(fā)送完一個分組，就會停止發(fā)送，必須受到對這個分組的確認才會繼續(xù)發(fā)送下一個分組

超時重傳：是指每發(fā)送一個分組，就會為這個分組啟動一個超時計數(shù)器，在規(guī)定的時間內(nèi)沒有受到確認，就會再次發(fā)送這個分組。

在連續(xù)ARQ協(xié)議中，為提高信道利用率，通常采取的做法是發(fā)送方維持一個發(fā)送窗口，凡是位于該窗口內(nèi)的分組都可以發(fā)送出去，無需等待確認，在接收方是采用累積確認，即對按需到達的分組后一個分組發(fā)送確認，表明在這個分組以前的所有分組都已正確接收到

擁塞控制與流量控制

流量控制是一個端到端的過程，是值接收方限制發(fā)送方的速率不要太快，使接收方來得及接收；擁塞控制是一個全局的過程，是只不要向網(wǎng)絡(luò)注入太多的數(shù)據(jù)，導致鏈路或者路由器損壞；

擁塞控制采用四種算法：慢開始和擁塞控制，快重傳和快恢復

慢開始是cwnd(擁塞窗口)每次回從1開始，每經(jīng)過一個往返時間，cwnd的值就會加倍；

擁塞避免是指每經(jīng)過一個往返時間，cwnd的值會加一，是一個線性的過程。

慢開始和擁塞避免:會設(shè)置一個慢開始門限，當cwnd《sshreh的時候，會采用滿開始算法，當超過這個值的時候，會采用擁塞避免的算法，當出現(xiàn)擁塞的時候，會把sshreh的值取為發(fā)送方窗口值當前的一半，再把cwnd取為1，從1開始使用滿開始算法。

快重傳和快恢復收到三個重復確認的時候，會把sshreh的值置為當前值的一半，與慢開始不同的是，它會把擁塞窗口的值取為當前慢開始門限的一半，執(zhí)行擁塞避免算法

快重傳要求接收方?jīng)]收到一段失序的報文段，就要向發(fā)送方發(fā)送一個確認

洪水攻擊

向服務(wù)器端發(fā)送大量的偽TCP連接請求，這時候服務(wù)器端會進入syn_receive半連接狀態(tài)，服務(wù)器端會嘗試發(fā)送多次包來確認，因為這些連接時假冒的，所以并不會完成第三次握手，導致服務(wù)器端保持大量的半連接狀態(tài)，耗費資源，是TCP連接隊列被塞滿。

解決方法：

做一些應(yīng)急處理，對這些IP地址的特征來禁止響應(yīng)的IP地址字段的訪問。

應(yīng)急處理畢竟太被動，因為本機房的F5比較空閑，運維利用F5來擋攻擊，采用方式：讓客戶端先和F5三次握手，連接建立之后F5才轉(zhuǎn)發(fā)到后端業(yè)務(wù)服務(wù)器。

掃一掃，歡迎關(guān)注我的公眾號 stormjun94。如果你有好的文章，也歡迎你的投稿。

總結(jié)

以上是生活随笔為你收集整理的android tcp 最优窗口,Android 面试必备 - 计算机网络基本知识（TCP，UDP，Http，https）...的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

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