【摘要】
今天在編寫socket,在期間遇到查看某個端口的狀態，隨后從網上找了一下，現在總結一下。
【內容】
大家都知道，端口不是獨立存在的，它是依附於進程的。某個進程開啟，那么它對應的端口就開啟了，進程關閉，則該端口也就關閉了。下次若某個進程再次開啟，則相應的端口也再次開啟。而不要純粹的理解為關閉掉某個端口，不過可以禁用某個端口。
1. 查看端口
【Command】
netstat -anp
注：加參數'-n'會將應用程序轉為端口顯示，即數字格式的地址，如：nfs->2049, ftp->21，因此可以開啟兩個終端，一一對應一下程序所對應的端口號)
【Command】
lsof -i:xxx
（注：有些端口通過netstat查不出來，更可靠的方法是"~$ sudo nmap -sT -O localhost"）
3. 關閉端口
【iptable】
sudo iptables -A INPUT -p tcp --dport $PORT -j DROP"
sudo iptables -A OUTPUT -p tcp --dport $PORT -j DROP"【kill】kill -9 PID" (PID：進程號)
1)通過iptables工具將該端口禁掉，如：
2)或者關掉對應的應用程序，則端口就自然關閉了
4. Kill
使用kill關閉進程使用的-9，下面介紹一下kill的使用, kill 實際的實際作用是給進程發信號（signal）， 其常用格式為
【Kill】
kill -sig pid
【Kill】
INT 2 這個就是你在bash下面用Ctrl+C 來結束一個程序時，bash會向進程發送這個信號，默認的，進程收到這個程序會結束。 你可以用 kill -INT pid 來發這個信號。 QUIT 3 這個是你在bash下用 Ctrl+\ 來結束程序時，發的信號，進程默認受到這個信號后也是結束 KILL 9 這個信號之所以被稱為“強殺”，就是因為無法改變進程收到這個信號后所執行的動作，進程只能退出。(前面說的兩個信號，雖然默認是退出，但是應用程序自己可以通過signal系統調用來修改成其他動作，比如忽略那兩個信號等動作)
當前在網絡傳輸應用中，廣泛采用的是TCP/IP通信協議及其標准的socket應用開發編程接口（API）。TCP/IP傳輸層有兩個並列的協議：TCP和UDP。其中TCP（transport control protocol，傳輸控制協議）是面向連接的，提供高可靠性服務。UDP（user datagram protocol，用戶數據報協議）是無連接的，提供高效率服務。在實際工程應用中，對可靠性和效率的選擇取決於應用的環境和需求。一般情況下，普通數據的網絡傳輸采用高效率的udp，重要數據的網絡傳輸采用高可靠性的TCP。
在應用開發過程中，筆者發現基於TCP網絡傳輸的應用程序有時會出現粘包現象（即發送方發送的若干包數據到接收方接收時粘成一包）。在流傳輸中出現，UDP不會出現粘包，因為它有消息邊界.
一、TCP協議簡介
TCP是一個面向連接的傳輸層協議，雖然TCP不屬於iso制定的協議集，但由於其在商業界和工業界的成功應用，它已成為事實上的網絡標准，廣泛應用於各種網絡主機間的通信。
作為一個面向連接的傳輸層協議，TCP的目標是為用戶提供可靠的端到端連接，保證信息有序無誤的傳輸。它除了提供基本的數據傳輸功能外，還為保證可靠性采用了數據編號、校驗和計算、數據確認等一系列措施。它對傳送的每個數據字節都進行編號，並請求接收方回傳確認信息（ack）。發送方如果在規定的時間內沒有收到數據確認，就重傳該數據。數據編號使接收方能夠處理數據的失序和重復問題。數據誤碼問題通過在每個傳輸的數據段中增加校驗和予以解決，接收方在接收到數據后檢查校驗和，若校驗和有誤，則丟棄該有誤碼的數據段，並要求發送方重傳。流量控制也是保證可靠性的一個重要措施，若無流控，可能會因接收緩沖區溢出而丟失大量數據，導致許多重傳，造成網絡擁塞惡性循環。TCP采用可變窗口進行流量控制，由接收方控制發送方發送的數據量。
TCP為用戶提供了高可靠性的網絡傳輸服務，但可靠性保障措施也影響了傳輸效率。因此，在實際工程應用中，只有關鍵數據的傳輸才采用TCP，而普通數據的傳輸一般采用高效率的udp。
二、粘包問題分析與對策
TCP粘包是指發送方發送的若干包數據到接收方接收時粘成一包，從接收緩沖區看，后一包數據的頭緊接着前一包數據的尾。
出現粘包現象的原因是多方面的，它既可能由發送方造成，也可能由接收方造成。發送方引起的粘包是由TCP協議本身造成的，TCP為提高傳輸效率，發送方往往要收集到足夠多的數據后才發送一包數據。若連續幾次發送的數據都很少，通常TCP會根據優化算法把這些數據合成一包后一次發送出去，這樣接收方就收到了粘包數據。接收方引起的粘包是由於接收方用戶進程不及時接收數據，從而導致粘包現象。這是因為接收方先把收到的數據放在系統接收緩沖區，用戶進程從該緩沖區取數據，若下一包數據到達時前一包數據尚未被用戶進程取走，則下一包數據放到系統接收緩沖區時就接到前一包數據之后，而用戶進程根據預先設定的緩沖區大小從系統接收緩沖區取數據，這樣就一次取到了多包數據（圖1所示）。
圖1
圖2
圖3
粘包情況有兩種，一種是粘在一起的包都是完整的數據包（圖1、圖2所示），另一種情況是粘在一起的包有不完整的包（圖3所示），此處假設用戶接收緩沖區長度為m個字節。
不是所有的粘包現象都需要處理，若傳輸的數據為不帶結構的連續流數據（如文件傳輸），則不必把粘連的包分開（簡稱分包）。但在實際工程應用中，傳輸的數據一般為帶結構的數據，這時就需要做分包處理。
在處理定長結構數據的粘包問題時，分包算法比較簡單；在處理不定長結構數據的粘包問題時，分包算法就比較復雜。特別是如圖3所示的粘包情況，由於一包數據內容被分在了兩個連續的接收包中，處理起來難度較大。實際工程應用中應盡量避免出現粘包現象。
為了避免粘包現象，可采取以下幾種措施。一是對於發送方引起的粘包現象，用戶可通過編程設置來避免，TCP提供了強制數據立即傳送的操作指令push，TCP軟件收到該操作指令后，就立即將本段數據發送出去，而不必等待發送緩沖區滿；二是對於接收方引起的粘包，則可通過優化程序設計、精簡接收進程工作量、提高接收進程優先級等措施，使其及時接收數據，從而盡量避免出現粘包現象；三是由接收方控制，將一包數據按結構字段，人為控制分多次接收，然后合並，通過這種手段來避免粘包。
以上提到的三種措施，都有其不足之處。第一種編程設置方法雖然可以避免發送方引起的粘包，但它關閉了優化算法，降低了網絡發送效率，影響應用程序的性能，一般不建議使用。第二種方法只能減少出現粘包的可能性，但並不能完全避免粘包，當發送頻率較高時，或由於網絡突發可能使某個時間段數據包到達接收方較快，接收方還是有可能來不及接收，從而導致粘包。第三種方法雖然避免了粘包，但應用程序的效率較低，對實時應用的場合不適合。
一種比較周全的對策是：接收方創建一預處理線程，對接收到的數據包進行預處理，將粘連的包分開。對這種方法我們進行了實驗，證明是高效可行的。
三、編程與實現
1．實現框架
實驗網絡通信程序采用TCP/IP協議的socket api編程實現。socket是面向客戶機/服務器模型的。TCP實現框架如圖4所示。
圖4
2．實驗硬件環境：
服務器：pentium 350 微機
客戶機：pentium 166微機
網絡平台：由10兆共享式hub連接而成的局域網
3．實驗軟件環境：
操作系統：windows 98
編程語言：visual c++ 5.0
4．主要線程
編程采用多線程方式，服務器端共有兩個線程：發送數據線程、發送統計顯示線程。客戶端共有三個線程：接收數據線程、接收預處理粘包線程、接收統計顯示線程。其中，發送和接收線程優先級設為thread_priority_time_critical（最高優先級），預處理線程優先級為thread_priority_above_normal（高於普通優先級），顯示線程優先級為thread_priority_normal（普通優先級）。
實驗發送數據的數據結構如圖5所示：
圖5
5．分包算法
針對三種不同的粘包現象，分包算法分別采取了相應的解決辦法。其基本思路是首先將待處理的接收數據流（長度設為m）強行轉換成預定的結構數據形式，並從中取出結構數據長度字段，即圖5中的n，而后根據n計算得到第一包數據長度。
1)若n
2)若n=m，則表明數據流內容恰好是一完整結構數據，直接將其存入臨時緩沖區即可。
3)若n>m，則表明數據流內容尚不夠構成一完整結構數據，需留待與下一包數據合並后再行處理。
對分包算法具體內容及軟件實現有興趣者，可與作者聯系。
TCP的擁塞控制
1.引言
計算機網絡中的帶寬、交換結點中的緩存和處理機等，都是網絡的資源。在某段時間，若對網絡中某一資源的需求超過了該資源所能提供的可用部分，網絡的性能就會變壞。這種情況就叫做擁塞。
擁塞控制就是防止過多的數據注入網絡中，這樣可以使網絡中的路由器或鏈路不致過載。擁塞控制是一個全局性的過程，和流量控制不同，流量控制指點對點通信量的控制。
2.慢開始與擁塞避免
發送方維持一個叫做擁塞窗口cwnd（congestion window）的狀態變量。擁塞窗口的大小取決於網絡的擁塞程度，並且動態地在變化。發送方讓自己的發送窗口等於擁塞窗口，另外考慮到接受方的接收能力，發送窗口可能小於擁塞窗口。
慢開始算法的思路就是，不要一開始就發送大量的數據，先探測一下網絡的擁塞程度，也就是說由小到大逐漸增加擁塞窗口的大小。
這里用報文段的個數的擁塞窗口大小舉例說明慢開始算法，實時擁塞窗口大小是以字節為單位的。如下圖：
當然收到單個確認但此確認多個數據報的時候就加相應的數值。所以一次傳輸輪次之后擁塞窗口就加倍。這就是乘法增長，和后面的擁塞避免算法的加法增長比較。
為了防止cwnd增長過大引起網絡擁塞，還需設置一個慢開始門限ssthresh狀態變量。ssthresh的用法如下：
當cwnd<ssthresh時，使用慢開始算法。
當cwnd>ssthresh時，改用擁塞避免算法。
當cwnd=ssthresh時，慢開始與擁塞避免算法任意。
擁塞避免算法讓擁塞窗口緩慢增長，即每經過一個往返時間RTT就把發送方的擁塞窗口cwnd加1，而不是加倍。這樣擁塞窗口按線性規律緩慢增長。
無論是在慢開始階段還是在擁塞避免階段，只要發送方判斷網絡出現擁塞（其根據就是沒有收到確認，雖然沒有收到確認可能是其他原因的分組丟失，但是因為無法判定，所以都當做擁塞來處理），就把慢開始門限設置為出現擁塞時的發送窗口大小的一半。然后把擁塞窗口設置為1，執行慢開始算法。如下圖：
再次提醒這里只是為了討論方便而將擁塞窗口大小的單位改為數據報的個數，實際上應當是字節。
3.快重傳和快恢復
快重傳要求接收方在收到一個失序的報文段后就立即發出重復確認（為的是使發送方及早知道有報文段沒有到達對方）而不要等到自己發送數據時捎帶確認。快重傳算法規定，發送方只要一連收到三個重復確認就應當立即重傳對方尚未收到的報文段，而不必繼續等待設置的重傳計時器時間到期。如下圖：
快重傳配合使用的還有快恢復算法，有以下兩個要點:
①當發送方連續收到三個重復確認時，就執行“乘法減小”算法，把ssthresh門限減半。但是接下去並不執行慢開始算法。
②考慮到如果網絡出現擁塞的話就不會收到好幾個重復的確認，所以發送方現在認為網絡可能沒有出現擁塞。所以此時不執行慢開始算法，而是將cwnd設置為ssthresh的大小，然后執行擁塞避免算法。如下圖：
4.隨機早期檢測RED
以上的擁塞避免算法並沒有和網絡層聯系起來，實際上網絡層的策略對擁塞避免算法影響最大的就是路由器的丟棄策略。在簡單的情況下路由器通常按照先進先出的策略處理到來的分組。當路由器的緩存裝不下分組的時候就丟棄到來的分組，這叫做尾部丟棄策略。這樣就會導致分組丟失，發送方認為網絡產生擁塞。更為嚴重的是網絡中存在很多的TCP連接，這些連接中的報文段通常是復用路由路徑。若發生路由器的尾部丟棄，可能影響到很多條TCP連接，結果就是這許多的TCP連接在同一時間進入慢開始狀態。這在術語中稱為全局同步。全局同步會使得網絡的通信量突然下降很多，而在網絡恢復正常之后，其通信量又突然增大很多。
為避免發生網路中的全局同步現象，路由器采用隨機早期檢測(RED:randomearly detection)。該算法要點如下：
使路由器的隊列維持兩個參數，即隊列長隊最小門限min和最大門限max，每當一個分組到達的時候，RED就計算平均隊列長度。然后分情況對待到來的分組：
①平均隊列長度小於最小門限——把新到達的分組放入隊列排隊。
②平均隊列長度在最小門限與最大門限之間——則按照某一概率將分組丟棄。
③平均隊列長度大於最大門限——丟棄新到達的分組。
以概率p隨機丟棄分組，讓擁塞控制只在個別的TCP連接上執行，因而避免全局性的擁塞控制。
RED的關鍵就是選擇三個參數最小門限、最大門限、丟棄概率和計算平均隊列長度。平均隊列長度采用加權平均的方法計算平均隊列長度，這和往返時間（RTT）的計算策略是一樣的。
為了防止網絡的擁塞現象，TCP提出了一系列的擁塞控制機制。最初由V. Jacobson在1988年的論文中提出的TCP的擁塞控制由“慢啟動(Slow start)”和“擁塞避免(Congestion avoidance)”組成，后來TCP Reno版本中又針對性的加入了“快速重傳(Fast retransmit)”、“快速恢復(Fast Recovery)”算法，再后來在TCP NewReno中又對“快速恢復”算法進行了改進，近些年又出現了選擇性應答( selective acknowledgement,SACK)算法，還有其他方面的大大小小的改進，成為網絡研究的一個熱點。
TCP的擁塞控制主要原理依賴於一個擁塞窗口(cwnd)來控制，在之前我們還討論過TCP還有一個對端通告的接收窗口(rwnd)用於流量控制。窗口值的大小就代表能夠發送出去的但還沒有收到ACK的最大數據報文段，顯然窗口越大那么數據發送的速度也就越快，但是也有越可能使得網絡出現擁塞，如果窗口值為1，那么就簡化為一個停等協議，每發送一個數據，都要等到對方的確認才能發送第二個數據包，顯然數據傳輸效率低下。TCP的擁塞控制算法就是要在這兩者之間權衡，選取最好的cwnd值，從而使得網絡吞吐量最大化且不產生擁塞。
由於需要考慮擁塞控制和流量控制兩個方面的內容，因此TCP的真正的發送窗口=min(rwnd, cwnd)。但是rwnd是由對端確定的，網絡環境對其沒有影響，所以在考慮擁塞的時候我們一般不考慮rwnd的值，我們暫時只討論如何確定cwnd值的大小。關於cwnd的單位，在TCP中是以字節來做單位的，我們假設TCP每次傳輸都是按照MSS大小來發送數據的，因此你可以認為cwnd按照數據包個數來做單位也可以理解，所以有時我們說cwnd增加1也就是相當於字節數增加1個MSS大小。
慢啟動：最初的TCP在連接建立成功后會向網絡中發送大量的數據包，這樣很容易導致網絡中路由器緩存空間耗盡，從而發生擁塞。因此新建立的連接不能夠一開始就大量發送數據包，而只能根據網絡情況逐步增加每次發送的數據量，以避免上述現象的發生。具體來說，當新建連接時，cwnd初始化為1個最大報文段(MSS)大小，發送端開始按照擁塞窗口大小發送數據，每當有一個報文段被確認，cwnd就增加1個MSS大小。這樣cwnd的值就隨着網絡往返時間(Round Trip Time,RTT)呈指數級增長，事實上，慢啟動的速度一點也不慢，只是它的起點比較低一點而已。我們可以簡單計算下：
開始 ---> cwnd = 1
經過1個RTT后 ---> cwnd = 2*1 = 2
經過2個RTT后 ---> cwnd = 2*2= 4
經過3個RTT后 ---> cwnd = 4*2 = 8
如果帶寬為W，那么經過RTT*log2W時間就可以占滿帶寬。
擁塞避免：從慢啟動可以看到，cwnd可以很快的增長上來，從而最大程度利用網絡帶寬資源，但是cwnd不能一直這樣無限增長下去，一定需要某個限制。TCP使用了一個叫慢啟動門限(ssthresh)的變量，當cwnd超過該值后，慢啟動過程結束，進入擁塞避免階段。對於大多數TCP實現來說，ssthresh的值是65536(同樣以字節計算)。擁塞避免的主要思想是加法增大，也就是cwnd的值不再指數級往上升，開始加法增加。此時當窗口中所有的報文段都被確認時，cwnd的大小加1，cwnd的值就隨着RTT開始線性增加，這樣就可以避免增長過快導致網絡擁塞，慢慢的增加調整到網絡的最佳值。
上面討論的兩個機制都是沒有檢測到擁塞的情況下的行為，那么當發現擁塞了cwnd又該怎樣去調整呢？
首先來看TCP是如何確定網絡進入了擁塞狀態的，TCP認為網絡擁塞的主要依據是它重傳了一個報文段。上面提到過，TCP對每一個報文段都有一個定時器，稱為重傳定時器(RTO)，當RTO超時且還沒有得到數據確認，那么TCP就會對該報文段進行重傳，當發生超時時，那么出現擁塞的可能性就很大，某個報文段可能在網絡中某處丟失，並且后續的報文段也沒有了消息，在這種情況下，TCP反應比較“強烈”：
1.把ssthresh降低為cwnd值的一半
2.把cwnd重新設置為1
3.重新進入慢啟動過程。
從整體上來講，TCP擁塞控制窗口變化的原則是AIMD原則，即加法增大、乘法減小。可以看出TCP的該原則可以較好地保證流之間的公平性，因為一旦出現丟包，那么立即減半退避，可以給其他新建的流留有足夠的空間，從而保證整個的公平性。
其實TCP還有一種情況會進行重傳：那就是收到3個相同的ACK。TCP在收到亂序到達包時就會立即發送ACK，TCP利用3個相同的ACK來判定數據包的丟失，此時進行快速重傳，快速重傳做的事情有：
1.把ssthresh設置為cwnd的一半
2.把cwnd再設置為ssthresh的值(具體實現有些為ssthresh+3)
3.重新進入擁塞避免階段。
后來的“快速恢復”算法是在上述的“快速重傳”算法后添加的，當收到3個重復ACK時，TCP最后進入的不是擁塞避免階段，而是快速恢復階段。快速重傳和快速恢復算法一般同時使用。快速恢復的思想是“數據包守恆”原則，即同一個時刻在網絡中的數據包數量是恆定的，只有當“老”數據包離開了網絡后，才能向網絡中發送一個“新”的數據包，如果發送方收到一個重復的ACK，那么根據TCP的ACK機制就表明有一個數據包離開了網絡，於是cwnd加1。如果能夠嚴格按照該原則那么網絡中很少會發生擁塞，事實上擁塞控制的目的也就在修正違反該原則的地方。
具體來說快速恢復的主要步驟是：
1.當收到3個重復ACK時，把ssthresh設置為cwnd的一半，把cwnd設置為ssthresh的值加3，然后重傳丟失的報文段，加3的原因是因為收到3個重復的ACK，表明有3個“老”的數據包離開了網絡。
2.再收到重復的ACK時，擁塞窗口增加1。
3.當收到新的數據包的ACK時，把cwnd設置為第一步中的ssthresh的值。原因是因為該ACK確認了新的數據，說明從重復ACK時的數據都已收到，該恢復過程已經結束，可以回到恢復之前的狀態了，也即再次進入擁塞避免狀態。
快速重傳算法首次出現在4.3BSD的Tahoe版本，快速恢復首次出現在4.3BSD的Reno版本，也稱之為Reno版的TCP擁塞控制算法。
可以看出Reno的快速重傳算法是針對一個包的重傳情況的，然而在實際中，一個重傳超時可能導致許多的數據包的重傳，因此當多個數據包從一個數據窗口中丟失時並且觸發快速重傳和快速恢復算法時，問題就產生了。因此NewReno出現了，它在Reno快速恢復的基礎上稍加了修改，可以恢復一個窗口內多個包丟失的情況。具體來講就是：Reno在收到一個新的數據的ACK時就退出了快速恢復狀態了，而NewReno需要收到該窗口內所有數據包的確認后才會退出快速恢復狀態，從而更一步提高吞吐量。
SACK就是改變TCP的確認機制，最初的TCP只確認當前已連續收到的數據，SACK則把亂序等信息會全部告訴對方，從而減少數據發送方重傳的盲目性。比如說序號1，2，3，5，7的數據收到了，那么普通的ACK只會確認序列號4，而SACK會把當前的5，7已經收到的信息在SACK選項里面告知對端，從而提高性能，當使用SACK的時候，NewReno算法可以不使用，因為SACK本身攜帶的信息就可以使得發送方有足夠的信息來知道需要重傳哪些包，而不需要重傳哪些包。