壓縮協議有-九游会j9娱乐平台

① 常見的文件壓縮格式各有什麼優缺點

對比四種常見文件壓縮格式的優缺點：

zip

優點在於廣泛性，zip格式被幾乎所有的壓縮軟體支持，而且windows操作系統在沒有安裝任何外部壓縮軟體的情況下也可以直接解壓zip文件，缺點是文件名為gbk編碼的windows操作系統製作的zip壓縮包在系統下顯示為亂碼，而且文件時間也只是記錄了一個時間值。

rar

優點是rar允許在規定的許可協議下被別的軟體解壓，rar在信息方面相比zip更全一些。rar的壓縮比率比zip格式要高，缺點就是壓縮和解壓速度比zip要慢。

7-zip

優點是開源強大、好用的壓縮軟體，支持解壓幾乎所有壓縮文件格式。

gzip

優點是gzip來歸檔文件這個壓縮標準是gzip，gzip同時被服務端和客戶端默認支持。

壓縮文件

簡單的說就是經過壓縮軟體壓縮的文件叫壓縮文件，壓縮的原理是把文件的二進制代碼壓縮，把相鄰的0、1代碼減少，比如有000000，可以把它變成6個0 的寫法60，來減少該文件的空間。

壓縮文件的基本原理是查找文件內的重復位元組，並建立一個相同位元組的詞典文件，並用一個代碼表示，比如在文件里有幾處有一個相同的詞中華人民共和國用一個代碼表示並寫入詞典文件，這樣就可以達到縮小文件的目的。

以上內容參考網路--壓縮文件

② tcp協議詳解及實戰解析【精心整理收藏】

tcp協議是在tcp/ip協議模型中的運輸層中很重要的一個協議、負責處理主機埠層面之間的數據傳輸。主要有以下特點：

1.tcp是面向鏈接的協議，在數據傳輸之前需要通過三次握手建立tcp鏈接，當數據傳遞完成之後，需要通過四次揮手進行連接釋放。

2.每一條tcp通信都是盯御擾兩台主機和主機之間的，是點對點傳輸的協議。

3.tcp提供可靠的、無差錯、不丟失、不重復，按序到達的服務。

4.tcp的通信雙方在連接建立的任何時候都可以發送數據。tcp連接的兩端都設有發送緩存和接收緩存，用來臨時存放雙向通信拆運的數據。

5.面向位元組流。在數據傳輸的過程中如果報文比較長的話tcp會進行數據分段傳輸，每一條分段的tcp傳輸信息都帶有分段的序號，每一段都包含一部分位元組流。接收方根據每段攜帶的的序號信息進行數據拼接，最終拼接出來初始的傳輸數據。但是在整個傳輸的過程中每一段tcp攜帶的都是被切割的位元組流數據。所以說tcp是面向位元組流的。

a.tcp和udp在發送報文時所採用的方式完全不同。tcp並不關心應用程序一次把多長的報文發送到tcp緩存中，而是根據對方給出的窗口值和當前網路擁塞的程度來決定一個報文段應包含多少個位元組（udp發送的報文長度是應用程序給出的）。
b.如果應用程序傳送到tcp緩存的數據塊太大，tcp就可以把它劃分短一些再傳。tcp也可以等待積累有足夠多的位元組後再構建成報文段發送出去。

各欄位含義：

源埠：發送端的埠號

目的埠：接收端的埠號

序號：tcp將發送報文分段傳輸的時候會給每一段加上序號，接收端也可以根據這個序號來判斷數據拼接的順序，主要用來解決網路報亂序的問題

確認號：確認號為接收端收到數據之後進行排序確認以及發送下一次期待接收到的序號，數值 = 接收到的發送號 1

數據偏移：佔4比特，表示數據開始的地方離tcp段的起始處有多遠。實際上就是tcp段首部的長度。由於首部長度不固定，因此數據偏移欄位是必要的。數據偏移以32位為長度單位，因此tcp首部的最大長度是60（15*4）個位元組。

控制位：

urg：此標志表示tcp包的緊急指針域有效，用來保證tcp連接不被中斷，並且督促 中間層設備要盡快處理這凱旦些數據;

ack：此標志表示應答域有效，就是說前面所說的tcp應答號將會包含在tcp數據包中;有兩個取值：0和1， 為1的時候表示應答域有效，反之為0;

psh：這個標志位表示push操作。所謂push操作就是指在數據包到達接收端以後，立即傳送給應用程序， 而不是在緩沖區中排隊;

rst：這個標志表示連接復位請求。用來復位那些產生錯誤的連接，也被用來拒絕錯誤和非法的數據包;

syn：表示同步序號，用來建立連接。syn標志位和ack標志位搭配使用，當連接請求的時候，syn=1， ack=0;連接被響應的時候，syn=1，ack=1;這個標志的數據包經常被用來進行埠掃描。掃描者發送 一個只有syn的數據包，如果對方主機響應了一個數據包回來 ，就表明這台主機存在這個埠;但是由於這 種掃描方式只是進行tcp三次握手的第一次握手，因此這種掃描的成功表示被掃描的機器不很安全，一台安全 的主機將會強制要求一個連接嚴格的進行tcp的三次握手;

fin： 表示發送端已經達到數據末尾，也就是說雙方的數據傳送完成，沒有數據可以傳送了，發送fin標志 位的tcp數據包後，連接將被斷開。這個標志的數據包也經常被用於進行埠掃描。

窗口：tcp里很重要的一個機制，佔2位元組，表示報文段發送方期望接收的位元組數，可接收的序號范圍是從接收方的確認號開始到確認號加上窗口大小之間的數據。後面會有實例講解。

校驗和：校驗和包含了偽首部、tcp首部和數據，校驗和是tcp強制要求的，由發送方計算，接收方驗證

緊急指針：urg標志為1時，緊急指針有效，表示數據需要優先處理。緊急指針指出在tcp段中的緊急數據的最後一個位元組的序號，使接收方可以知道緊急數據共有多長。

選項：最常用的選項是最大段大小（maximum segment size，mss），向對方通知本機可以接收的最大tcp段長度。mss選項只在建立連接的請求中發送。

放在乙太網幀里看tcp的位置

tcp 數據包在 ip 數據包的負載裡面。它的頭信息最少也需要20位元組，因此 tcp 數據包的最大負載是 1480 - 20 = 1460 位元組。由於 ip 和 tcp 協議往往有額外的頭信息，所以 tcp 負載實際為1400位元組左右。

因此，一條1500位元組的信息需要兩個 tcp 數據包。http/2 協議的一大改進， 就是壓縮 http 協議的頭信息，使得一個 http 請求可以放在一個 tcp 數據包裡面，而不是分成多個，這樣就提高了速度。

乙太網數據包的負載是1500位元組，tcp 數據包的負載在1400位元組左右

一個包1400位元組，那麼一次性發送大量數據，就必須分成多個包。比如，一個 10mb 的文件，需要發送7100多個包。

發送的時候，tcp 協議為每個包編號（sequence number，簡稱 seq），以便接收的一方按照順序還原。萬一發生丟包，也可以知道丟失的是哪一個包。

第一個包的編號是一個隨機數。為了便於理解，這里就把它稱為1號包。假定這個包的負載長度是100位元組，那麼可以推算出下一個包的編號應該是101。這就是說，每個數據包都可以得到兩個編號：自身的編號，以及下一個包的編號。接收方由此知道，應該按照什麼順序將它們還原成原始文件。

收到 tcp 數據包以後，組裝還原是操作系統完成的。應用程序不會直接處理 tcp 數據包。

對於應用程序來說，不用關心數據通信的細節。除非線路異常，否則收到的總是完整的數據。應用程序需要的數據放在 tcp 數據包裡面，有自己的格式（比如 http 協議）。

tcp 並沒有提供任何機制，表示原始文件的大小，這由應用層的協議來規定。比如，http 協議就有一個頭信息content-length，表示信息體的大小。對於操作系統來說，就是持續地接收 tcp 數據包，將它們按照順序組裝好，一個包都不少。

操作系統不會去處理 tcp 數據包裡面的數據。一旦組裝好 tcp 數據包，就把它們轉交給應用程序。tcp 數據包裡面有一個埠（port）參數，就是用來指定轉交給監聽該埠的應用程序。

應用程序收到組裝好的原始數據，以瀏覽器為例，就會根據 http 協議的content-length欄位正確讀出一段段的數據。這也意味著，一次 tcp 通信可以包括多個 http 通信。

伺服器發送數據包，當然越快越好，最好一次性全發出去。但是，發得太快，就有可能丟包。帶寬小、路由器過熱、緩存溢出等許多因素都會導致丟包。線路不好的話，發得越快，丟得越多。

最理想的狀態是，在線路允許的情況下，達到最高速率。但是我們怎麼知道，對方線路的理想速率是多少呢？答案就是慢慢試。

tcp 協議為了做到效率與可靠性的統一，設計了一個慢啟動（slow start）機制。開始的時候，發送得較慢，然後根據丟包的情況，調整速率：如果不丟包，就加快發送速度；如果丟包，就降低發送速度。

linux 內核裡面 設定 了（常量tcp_init_cwnd），剛開始通信的時候，發送方一次性發送10個數據包，即"發送窗口"的大小為10。然後停下來，等待接收方的確認，再繼續發送。

默認情況下，接收方每收到 兩個 tcp 數據包，就要 發送 一個確認消息。"確認"的英語是 acknowledgement，所以這個確認消息就簡稱 ack。

ack 攜帶兩個信息。

發送方有了這兩個信息，再加上自己已經發出的數據包的最新編號，就會推測出接收方大概的接收速度，從而降低或增加發送速率。這被稱為"發送窗口"，這個窗口的大小是可變的。

注意，由於 tcp 通信是雙向的，所以雙方都需要發送 ack。兩方的窗口大小，很可能是不一樣的。而且 ack 只是很簡單的幾個欄位，通常與數據合並在一個數據包裡面發送。

即使對於帶寬很大、線路很好的連接，tcp 也總是從10個數據包開始慢慢試，過了一段時間以後，才達到最高的傳輸速率。這就是 tcp 的慢啟動。

tcp 協議可以保證數據通信的完整性，這是怎麼做到的？

前面說過，每一個數據包都帶有下一個數據包的編號。如果下一個數據包沒有收到，那麼 ack 的編號就不會發生變化。

舉例來說，現在收到了4號包，但是沒有收到5號包。ack 就會記錄，期待收到5號包。過了一段時間，5號包收到了，那麼下一輪 ack 會更新編號。如果5號包還是沒收到，但是收到了6號包或7號包，那麼 ack 裡面的編號不會變化，總是顯示5號包。這會導致大量重復內容的 ack。

如果發送方發現收到 三個 連續的重復 ack，或者超時了還沒有收到任何 ack，就會確認丟包，即5號包遺失了，從而再次發送這個包。通過這種機制，tcp 保證了不會有數據包丟失。

tcp是一個滑動窗口協議，即一個tcp連接的發送端在某個時刻能發多少數據是由滑動窗口控制的，而滑動窗口的大小實際上是由兩個窗口共同決定的，一個是接收端的通告窗口，這個窗口值在tcp協議頭部信息中有，會隨著數據的ack包發送給發送端，這個值表示的是在接收端的tcp協議緩存中還有多少剩餘空間，發送端必須保證發送的數據不超過這個剩餘空間以免造成緩沖區溢出，這個窗口是接收端用來進行流量限制的，在傳輸過程中，通告窗口大小與接收端的進程取出數據的快慢有關。另一個窗口是發送端的擁塞窗口(congestion window)，由發送端維護這個值，在協議頭部信息中沒有，滑動窗口的大小就是通告窗口和擁塞窗口的較小值，所以擁塞窗口也看做是發送端用來進行流量控制的窗口。滑動窗口的左邊沿向右移動稱為窗口合攏，發生在發送的數據被確認時（此時，表明數據已被接收端收到，不會再被需要重傳，可以從發送端的發送緩存中清除了），滑動窗口的右邊沿向右移動稱為窗口張開，發生在接收進程從接收端協議緩存中取出數據時。隨著發送端不斷收到的被發送數據的ack包，根據ack包中的確認序號和通告窗口大小使滑動窗口得以不斷的合攏和張開，形成滑動窗口的向前滑動。如果接收進程一直不取數據，則會出現0窗口現象，即滑動窗口左邊沿與右邊沿重合，此時窗口大小為0，就無法再發送數據。

在tcp里，接收端(b)會給發送端(a)報一個窗口的大小，叫advertised window。

1.在沒有收到b的確認情況下，a可以連續把窗口內的數據都發送出去。凡是已經發送過的數據，在

未收到確認之前都必須暫時保留，以便在超時重傳時使用。

2.發送窗口裡面的序號表示允許發送的序號。顯然，窗口越大，發送方就可以在收到對方確認之前連續

發送更多數據，因而可能獲得更高的傳輸效率。但接收方必須來得及處理這些收到的數據。

3.發送窗口後沿的後面部分表示已發送且已收到確認。這些數據顯然不需要再保留了。

4.發送窗口前沿的前面部分表示不允許發送的，應為接收方都沒有為這部分數據保留臨時存放的緩存空間。

5.發送窗口後沿的變化情況有兩種：不動（沒有收到新的確認）和前移（收到了新的確認）

6.發送窗口前沿的變化情況有兩種：不斷向前移或可能不動（沒收到新的確認）

tcp的發送方在規定時間內沒有收到確認就要重傳已發送的報文段。這種重傳的概念很簡單，但重傳時間的選擇確是tcp最復雜的問題之一。tcp採用了一種自適應演算法，它記錄一個報文段發出的時間，以及收到響應的確認的時間

這兩個時間之差就是報文段的往返時間rtt。tcp保留了rtt的一個加權平均往返時間。超時重傳時間rto略大於加權平均往返時間

rtt：
即round trip time，表示從發送端到接收端的一去一回需要的時間，tcp在數據傳輸過程中會對rtt進行采樣（即對發送的數據包及其ack的時間差進行測量，並根據測量值更新rtt值，具體的演算法tcpip詳解裡面有），tcp根據得到的rtt值更新rto值，即retransmission timeout，就是重傳間隔，發送端對每個發出的數據包進行計時，如果在rto時間內沒有收到所發出的數據包的對應ack，則任務數據包丟失，將重傳數據。一般rto值都比采樣得到的rtt值要大。

如果收到的報文段無差錯，只是未按序號，中間還缺少一些序號的數據，那麼能否設法只傳送缺少的數據而不重傳已經正確到達接收方的數據？

答案是可以的，選擇確認就是一種可行的處理方法。

如果要使用選項確認sack，那麼在建立tcp連接時，就要在tcp首部的選項中加上「允許sack」的選項，而雙方必須都事先商定好。如果使用選擇確認，

那麼原來首部中的「確認號欄位」的用法仍然不變。sack文檔並沒有明確發送方應當怎麼響應sack.因此大多數的實現還是重傳所有未被確認的數據塊。

一般說來，我們總是希望數據傳輸的更快一些，但如果發送方把數據發送的過快，接收方就可能來不及接收，這會造成數據的丟失。所謂流量控制就是讓發送方的發送速率不要太快，要讓接收方來得及接收。

在計算機網路中的鏈路容量，交換節點中的緩存和處理機等，都是網路的資源。在某段時間，若對網路中某一資源的需求超過了該資源所能提供的可用部分，網路的性能就要變壞。這種情況就叫做擁塞。

擁塞控制方法：

1.慢開始和擁塞避免

2.快重傳和快恢復

3.隨機早期檢測

1.一開始，客戶端和服務端都處於closed狀態

2.先是服務端主動監聽某個埠，處於listen狀態（比如服務端啟動，開始監聽）。

3.客戶端主動發起連接syn，之後處於syn-sent狀態（第一次握手，發送 syn = 1 ack = 0 seq = x ack = 0）。

4.服務端收到發起的連接，返回syn，並且ack客戶端的syn，之後處於syn-rcvd狀態（第二次握手，發送 syn = 1 ack = 1 seq = y ack = x 1）。

5.客戶端收到服務端發送的syn和ack之後，發送ack的ack，之後處於established狀態（第三次握手，發送 syn = 0 ack = 1 seq = x 1 ack = y 1）。

6.服務端收到客戶端的ack之後，處於established狀態。

（需要注意的是，有可能x和y是相等的，可能都是0，因為他們代表了各自發送報文段的序號。）

tcp連接釋放四次揮手

1.當前a和b都處於estab-lished狀態。

2.a的應用進程先向其tcp發出連接釋放報文段，並停止再發送數據，主動關閉tcp連接。

3.b收到連接釋放報文段後即發出確認，然後b進入close-wait(關閉等待)狀態。tcp伺服器進程這時應通知高層應用進程，因而從a到b這個方向的連接就釋放了，這時tcp連接處於半關閉狀態，即a已經沒有數據發送了。

從b到a這個方向的連接並未關閉，這個狀態可能會持續一些時間。

4.a收到來自b的確認後，就進入fin-wait-2(終止等待2)狀態，等待b發出的連接釋放報文端。

5.若b已經沒有向a發送的數據，b發出連接釋放信號，這時b進入last-ack(最後確認)狀態等待a的確認。

6.a再收到b的連接釋放消息後，必須對此發出確認，然後進入time-wait（時間等待）狀態。請注意，現在tcp連接還沒有釋放掉，必須經過時間等待計時器（time－wait timer）設置的時間2msl後，a才進入closed狀態。

7。b收到a發出的確認消息後，進入closed狀態。

以請求網路為例，看一下三次握手真實數據的tcp連接建立過程

我們再來看四次揮手。tcp斷開連接時，會有四次揮手過程，標志位是fin，我們在封包列表中找到對應位置，理論上應該找到4個數據包，但我試了好幾次，實際只抓到3個數據包。查了相關資料，說是因為伺服器端在給客戶端傳回的過程中，將兩個連續發送的包進行了合並。因此下面會按照合並後的三次揮手解釋，若有錯誤之處請指出。

第一步，當主機a的應用程序通知tcp數據已經發送完畢時，tcp向主機b發送一個帶有fin附加標記的報文段（fin表示英文finish）。

第二步，主機b收到這個fin報文段之後，並不立即用fin報文段回復主機a，而是先向主機a發送一個確認序號ack，同時通知自己相應的應用程序：對方要求關閉連接（先發送ack的目的是為了防止在這段時間內，對方重傳fin報文段）。

第三步，主機b的應用程序告訴tcp：我要徹底的關閉連接，tcp向主機a送一個fin報文段。

第四步，主機a收到這個fin報文段後，向主機b發送一個ack表示連接徹底釋放。

這是因為服務端在listen狀態下，收到建立連接請求的syn報文後，把ack和syn放在一個報文里發送給客戶端。而關閉連接時，當收到對方的fin報文時，僅僅表示對方不再發送數據了但是還能接收數據，己方也未必全部數據都發送給對方了，所以己方可以立即close，也可以發送一些數據給對方後，再發送fin報文給對方來表示同意現在關閉連接，因此，己方ack和fin一般都會分開發送。

原因有二：
一、保證tcp協議的全雙工連接能夠可靠關閉
二、保證這次連接的重復數據段從網路中消失

先說第一點，如果client直接closed了，那麼由於ip協議的不可靠性或者是其它網路原因，導致server沒有收到client最後回復的ack。那麼server就會在超時之後繼續發送fin，此時由於client已經closed了，就找不到與重發的fin對應的連接，最後server就會收到rst而不是ack，server就會以為是連接錯誤把問題報告給高層。這樣的情況雖然不會造成數據丟失，但是卻導致tcp協議不符合可靠連接的要求。所以，client不是直接進入closed，而是要保持time_wait，當再次收到fin的時候，能夠保證對方收到ack，最後正確的關閉連接。

再說第二點，如果client直接closed，然後又再向server發起一個新連接，我們不能保證這個新連接與剛關閉的連接的埠號是不同的。也就是說有可能新連接和老連接的埠號是相同的。一般來說不會發生什麼問題，但是還是有特殊情況出現：假設新連接和已經關閉的老連接埠號是一樣的，如果前一次連接的某些數據仍然滯留在網路中，這些延遲數據在建立新連接之後才到達server，由於新連接和老連接的埠號是一樣的，又因為tcp協議判斷不同連接的依據是socket pair，於是，tcp協議就認為那個延遲的數據是屬於新連接的，這樣就和真正的新連接的數據包發生混淆了。所以tcp連接還要在time_wait狀態等待2倍msl，這樣可以保證本次連接的所有數據都從網路中消失。

硬體速度
網路和伺服器的負載
請求和響應報文的尺寸
客戶端和伺服器之間的距離
tcp 協議的技術復雜性

tcp 連接建立握手；
tcp 慢啟動擁塞控制；
數據聚集的 nagle 演算法；
用於捎帶確認的 tcp 延遲確認演算法；
time_wait 時延和埠耗盡。

介紹完畢，就這？
是的，就這。

補充：

大部分內容為網路整理，方便自己學習回顧，參考文章：
tcp 協議簡介
tcp協議圖文詳解
什麼是tcp協議？
wireshark抓包分析——tcp/ip協議
tcp協議的三次握手和四次揮手
tcp協議詳解
tcp帶寬和時延的研究(1)

③ ip控制協議的tcp/ip包頭壓縮

van jacobson tcp/ip包頭壓縮降低了tcp/ip包頭的大小到接近3個位元組，這對於慢速的串列線路來說是一大提高。ip壓縮協議配置選項用於指示接收壓縮包的能力。如果需要兩個方向都進行壓縮則需要雙方獨立申請。 在傳送ip包時ppp協議域被設置為以下值：
0021 類型ip。ip協議不是tcp，或包是一個數據段，或未經過壓縮。
002d 壓縮的tcp。tcp/ip包頭由壓縮的包頭替換。
002f 未壓縮的tcp. ip協神帶謹議域由槽（slot）標記取代。 ip壓縮協議配置行渣選項格式如下所示，傳送順序從左至右：
類型 2
長度 6
ip壓縮協議
002d指示van jacobson compressed tcp/ip包頭。max-slot-id域一個位元組，指示最大的槽標記，它比實際的槽數少一，槽標記從0到max-slot-id。在實際中，如果max-slot-id = 0，可能會有問題。comp-slot-id域一個位元組，游基指示槽標記域是否壓縮。
0 槽標記不得壓縮。所有壓縮的tcp包必須在每個變更掩碼（change mask）中設置c位，並要包括槽標記。
1 可壓縮槽標記。