網路編程為什麼要雙緩沖區

① 我的畢業設計是一片關於網路滲透技術的論文，求能人給點相關的資料和文獻，本人是毫無頭緒啊。

[計算機科學與技術 ]Web服務緩沖區溢出滲透測試的設計與實現
http://ww2.tabobo.cn/soft/20/233/2007/14452478777.html

摘 要
緩沖區溢出漏洞是安全漏洞中最為常見的一種形式。更為嚴重的是緩沖區溢出漏洞佔了遠程網路攻擊的絕大多數，這種攻擊可以使的一個匿名的Internet用戶有機會獲得一台主機的部分或全部的控制權。由於這類攻擊使任何人都有可能取得主機的控制權，所以它代表了一類極其嚴重的安全威脅。因此，以緩沖區溢出作為一種滲透測試的手段是非常有意義的。
緩沖區溢出是滲透測試中的重要手段。現在大多數緩沖區溢出程序都是基於C/S架構的，所以其使用的便捷性受到一定限制。本課題採用現在最流行的B/S架構，並且最終實現了將緩沖區溢出作為Web服務來檢測遠程主機有無溢出漏洞並提醒用戶盡快修補此漏洞的目的。本文深入介紹了緩沖區溢出的原理，以及三種常見的緩沖區溢出漏洞；實例化地介紹了緩沖區溢出程序的執行流程；shellcode的編寫技術；java網路編程技術。
在對原理研究的基礎之上，本文主要給出了緩沖區溢出作為Web服務的設計和實現過程以及Web服務的其他輔助功能塊（網路安全新聞管理、網路安全論壇）的設計和實現。其中緩沖區溢出模塊和監聽模塊採用JavaBean技術實現，其他部分均採用JSP技術加以實現。
總的來說，本滲透測試平台實現了緩沖區溢出的方便性和廣范性以及安全性，並且可以載入任意的已經編譯成可執行文件的溢出程序。比起傳統的C/S架構下的測試平台前進了一大步。

關鍵字：滲透測試、緩沖區溢出、JSP

目 錄
摘要 1
Abstract 2
第一章 緒論 5
1.1 課題背景 5
1.2滲透測試概述 5
1.2.1滲透測試的的專業性 6
1.2.2 滲透測試的三個階段 6
1.3 論文安排 8
第二章 緩沖區溢出攻擊技術 9
2.1 緩沖區溢出基本原理 9
2.2 常見的緩沖區溢出形式 11
2.2.1 棧溢出 11
2.2.2 堆溢出 12
2.2.3 格式化字元串溢出 13
2.3 緩沖區溢出執行流程 16
2.4 shellcode技術 19
2.4.1 shellcode的編寫語言 19
2.4.2 shellcode本身代碼的重定位 20
2.4.3 shellcode編碼 21
第三章 Java網路編程技術介紹.23
3.1 JavaBean技術 23
3.1.1 JavaBean的概念 23
3.1.2 JavaBean的特性 23
3.1.3 JavaBean的屬性23
3.1.4 JavaBean在JSP頁面里的部署24
3.2 socket網路編程技術 .24
3.3 Java數據流 25
3.3.1 數據流的基本概念 25
3.3.2 數據流的分類介紹 25
第四章 緩沖區溢出滲透測試平台的設計與實現 27
4.1 測試平台框架設計27
4.1.1整體框架設計 27
4.1.2網路安全新聞發布模塊設計 28
4.1.3網路安全論壇模塊設計 29
4.1.4緩沖區溢出滲透測試模塊設計 31
4.2 緩沖區溢出滲透測試編碼實現 34
4.2.1緩沖區溢出漏洞選擇 34
4.2.2溢出模塊實現 34
4.2.3監聽模塊實現 34
4.2.4本地執行命令實現 36
4.2.5緩沖區溢出狀態實現 39
第五章 實驗設計和實驗數據 42
5.1實驗准備 42
5.2 SqlServer2000打sp3補丁前 43
5.2.1實驗數據 43
5.3 SqlServer2000打sp3補丁後 45
5.3.1實驗數據 45
結束語 47
參考文獻 48
致 謝 49

② 網路編程里的同步和非同步有啥區別的

網路編程中，同步的意思是說，進行收發數據，等到數據真正發送出去或者接受到，才返回；而非同步的意思是，可以把數據發送到緩沖區立即返回，而發送成功的消息是通過事件通知的。非同步可以騰出更多的CPU來處理其他事情，所以非同步的方式比較靈活。 線程同步是指，多個線程協同完成一件工作，一個線程需要等待其他線程完成相關的工作，才能接著往下運行。線程同步一般採用互斥體，信號量，消息等方式。

③ java Nio讀寫為什麼是雙向

作者：美團技術團隊
鏈接：https://zhuanlan.hu.com/p/23488863
來源：知乎
著作權歸作者所有。商業轉載請聯系作者獲得授權，非商業轉載請註明出處。

NIO（Non-blocking I/O，在Java領域，也稱為New I/O），是一種同步非阻塞的I/O模型，也是I/O多路復用的基礎，已經被越來越多地應用到大型應用伺服器，成為解決高並發與大量連接、I/O處理問題的有效方式。

那麼NIO的本質是什麼樣的呢？它是怎樣與事件模型結合來解放線程、提高系統吞吐的呢？

本文會從傳統的阻塞I/O和線程池模型面臨的問題講起，然後對比幾種常見I/O模型，一步步分析NIO怎麼利用事件模型處理I/O，解決線程池瓶頸處理海量連接，包括利用面向事件的方式編寫服務端/客戶端程序。最後延展到一些高級主題，如Reactor與Proactor模型的對比、Selector的喚醒、Buffer的選擇等。

註：本文的代碼都是偽代碼，主要是為了示意，不可用於生產環境。

傳統BIO模型分析

讓我們先回憶一下傳統的伺服器端同步阻塞I/O處理（也就是BIO，Blocking I/O）的經典編程模型：

{
ExecutorService executor = Excutors.newFixedThreadPollExecutor(100);//線程池

ServerSocket serverSocket = new ServerSocket();
serverSocket.bind(8088);
while(!Thread.currentThread.isInturrupted()){//主線程死循環等待新連接到來
Socket socket = serverSocket.accept();
executor.submit(new ConnectIOnHandler(socket));//為新的連接創建新的線程
}

class ConnectIOnHandler extends Thread{
private Socket socket;
public ConnectIOnHandler(Socket socket){
this.socket = socket;
}
public void run(){
while(!Thread.currentThread.isInturrupted()&&!socket.isClosed()){死循環處理讀寫事件
String someThing = socket.read()....//讀取數據
if(someThing!=null){
......//處理數據
socket.write()....//寫數據
}

}
}
}

這是一個經典的每連接每線程的模型，之所以使用多線程，主要原因在於socket.accept()、socket.read()、socket.write()三個主要函數都是同步阻塞的，當一個連接在處理I/O的時候，系統是阻塞的，如果是單線程的話必然就掛死在那裡；但CPU是被釋放出來的，開啟多線程，就可以讓CPU去處理更多的事情。其實這也是所有使用多線程的本質：

• 利用多核。

• 當I/O阻塞系統，但CPU空閑的時候，可以利用多線程使用CPU資源。

現在的多線程一般都使用線程池，可以讓線程的創建和回收成本相對較低。在活動連接數不是特別高（小於單機1000）的情況下，這種模型是比較不錯的，可以讓每一個連接專注於自己的I/O並且編程模型簡單，也不用過多考慮系統的過載、限流等問題。線程池本身就是一個天然的漏斗，可以緩沖一些系統處理不了的連接或請求。

不過，這個模型最本質的問題在於，嚴重依賴於線程。但線程是很"貴"的資源，主要表現在：

• 線程的創建和銷毀成本很高，在linux這樣的操作系統中，線程本質上就是一個進程。創建和銷毀都是重量級的系統函數。

• 線程本身佔用較大內存，像Java的線程棧，一般至少分配512K～1M的空間，如果系統中的線程數過千，恐怕整個JVM的內存都會被吃掉一半。

• 線程的切換成本是很高的。操作系統發生線程切換的時候，需要保留線程的上下文，然後執行系統調用。如果線程數過高，可能執行線程切換的時間甚至會大於線程執行的時間，這時候帶來的表現往往是系統load偏高、CPU sy使用率特別高（超過20%以上)，導致系統幾乎陷入不可用的狀態。

• 容易造成鋸齒狀的系統負載。因為系統負載是用活動線程數或CPU核心數，一旦線程數量高但外部網路環境不是很穩定，就很容易造成大量請求的結果同時返回，激活大量阻塞線程從而使系統負載壓力過大。

所以，當面對十萬甚至百萬級連接的時候，傳統的BIO模型是無能為力的。隨著移動端應用的興起和各種網路游戲的盛行，百萬級長連接日趨普遍，此時，必然需要一種更高效的I/O處理模型。

NIO是怎麼工作的

很多剛接觸NIO的人，第一眼看到的就是Java相對晦澀的API，比如：Channel，Selector，Socket什麼的；然後就是一坨上百行的代碼來演示NIO的服務端Demo……瞬間頭大有沒有？

我們不管這些，拋開現象看本質，先分析下NIO是怎麼工作的。

常見I/O模型對比

所有的系統I/O都分為兩個階段：等待就緒和操作。舉例來說，讀函數，分為等待系統可讀和真正的讀；同理，寫函數分為等待網卡可以寫和真正的寫。

需要說明的是等待就緒的阻塞是不使用CPU的，是在「空等」；而真正的讀寫操作的阻塞是使用CPU的，真正在"幹活"，而且這個過程非常快，屬於memory ，帶寬通常在1GB/s級別以上，可以理解為基本不耗時。

下圖是幾種常見I/O模型的對比：



密碼：380p

以上都是小編收集了大神的靈葯，喜歡的拿走吧！喜歡小編就輕輕關注一下吧！

④ linux網路編程，為什麼要將文件描述符設置成非阻塞模式

非阻塞IO 和阻塞IO：

在網路編程中對於一個網路句柄會遇到阻塞IO 和非阻塞IO 的概念, 這里對於這兩種socket 先做一下說明：
基本概念：
阻塞IO::
socket 的阻塞模式意味著必須要做完IO 操作（包括錯誤）才會
返回。
非阻塞IO::
非阻塞模式下無論操作是否完成都會立刻返回，需要通過其他方
式來判斷具體操作是否成功。(對於connect，accpet操作，通過select判斷，
對於recv，recvfrom，send，sendto通過返回值+錯誤碼來判斷)

IO模式設置：
SOCKET
對於一個socket 是阻塞模式還是非阻塞模式的處理方法::
方法：：
用fcntl 設置;用F_GETFL獲取flags,用F_SETFL設置flags|O_NONBLOCK;
同時，recv,send 時使用非阻塞的方式讀取和發送消息，即flags設置為MSG_DONTWAIT
實現
fcntl 函數可以將一個socket 句柄設置成非阻塞模式:
flags = fcntl(sockfd, F_GETFL, 0); //獲取文件的flags值。
fcntl(sockfd, F_SETFL, flags | O_NONBLOCK); //設置成非阻塞模式；
flags = fcntl(sockfd,F_GETFL,0);
fcntl(sockfd,F_SETFL,flags&~O_NONBLOCK); //設置成阻塞模式；
並在接收和發送數據時:
將recv, send 函數的最後有一個flag 參數設置成MSG_DONTWAIT
recv(sockfd, buff, buff_size,MSG_DONTWAIT); //非阻塞模式的消息發送
send(scokfd, buff, buff_size, MSG_DONTWAIT); //非阻塞模式的消息接受

普通文件
對於文件的阻塞模式還是非阻塞模式::
方法1、open時，使用O_NONBLOCK；
方法2、fcntl設置，使用F_SETFL，flags|O_NONBLOCK；

消息隊列
對於消息隊列消息的發送與接受::
//非阻塞 msgsnd(sockfd,msgbuf,msgsize(不包含類型大小),IPC_NOWAIT)
//阻塞 msgrcv(scokfd,msgbuf,msgsize(**),msgtype,IPC_NOWAIT);

讀
阻塞與非阻塞讀的區別: //阻塞和非阻塞的區別在於沒有數據到達的時候是否立刻返回．
讀(read/recv/msgrcv):
讀的本質來說其實不能是讀,在實際中, 具體的接收數據不是由這些調用來進行,是由於系統底層自動完成的。read 也好,recv 也好只負責把數據從底層緩沖 到我們指定的位置.
對於讀來說(read, 或者recv) ::
阻塞情況下::
在阻塞條件下，read/recv/msgrcv的行為::
1、如果沒有發現數據在網路緩沖中會一直等待，
2、當發現有數據的時候會把數據讀到用戶指定的緩沖區，但是如果這個時候讀到的數據量比較少，比參數中指定的長度要小，read 並不會一直等待下去，而是立刻返回。
read 的原則::是數據在不超過指定的長度的時候有多少讀多少，沒有數據就會一直等待。
所以一般情況下::我們讀取數據都需要採用循環讀的方式讀取數據，因為一次read 完畢不能保證讀到我們需要長度的數據，
read 完一次需要判斷讀到的數據長度再決定是否還需要再次讀取。
非阻塞情況下::
在非阻塞的情況下，read 的行為::
1、如果發現沒有數據就直接返回，
2、如果發現有數據那麼也是採用有多少讀多少的進行處理．
所以::read 完一次需要判斷讀到的數據長度再決定是否還需要再次讀取。

對於讀而言:: 阻塞和非阻塞的區別在於沒有數據到達的時候是否立刻返回．
recv 中有一個MSG_WAITALL 的參數::
recv(sockfd, buff, buff_size, MSG_WAITALL),
在正常情況下recv 是會等待直到讀取到buff_size 長度的數據，但是這里的WAITALL 也只是盡量讀全，在有中斷的情況下recv 還是可能會被打斷，造成沒有讀完指定的buff_size的長度。
所以即使是採用recv + WAITALL 參數還是要考慮是否需要循環讀取的問題，在實驗中對於多數情況下recv (使用了MSG_WAITALL)還是可以讀完buff_size，
所以相應的性能會比直接read 進行循環讀要好一些。

注意:: //使用MSG_WAITALL時，sockfd必須處於阻塞模式下，否則不起作用。
//所以MSG_WAITALL不能和MSG_NONBLOCK同時使用。
要注意的是使用MSG_WAITALL的時候，sockfd 必須是處於阻塞模式下，否則WAITALL不能起作用。

寫

阻塞與非阻塞寫的區別: //
寫(send/write/msgsnd)::
寫的本質也不是進行發送操作,而是把用戶態的數據 到系統底層去,然後再由系統進行發送操作,send，write返回成功，只表示數據已經 到底層緩沖,而不表示數據已經發出,更不能表示對方埠已經接收到數據.
對於write(或者send)而言，
阻塞情況下:: //阻塞情況下，write會將數據發送完。(不過可能被中斷)
在阻塞的情況下，是會一直等待，直到write 完，全部的數據再返回．這點行為上與讀操作有所不同。
原因::
讀，究其原因主要是讀數據的時候我們並不知道對端到底有沒有數據，數據是在什麼時候結束發送的，如果一直等待就可能會造成死循環，所以並沒有去進行這方面的處理；
寫，而對於write, 由於需要寫的長度是已知的，所以可以一直再寫，直到寫完．不過問題是write 是可能被打斷嗎，造成write 一次只write 一部分數據, 所以write 的過程還是需要考慮循環write, 只不過多數情況下一次write 調用就可能成功.

非阻塞寫的情況下:: //
非阻塞寫的情況下，是採用可以寫多少就寫多少的策略．與讀不一樣的地方在於，有多少讀多少是由網路發送的那一端是否有數據傳輸到為標准，但是對於可以寫多少是由本地的網路堵塞情況為標準的，在網路阻塞嚴重的時候，網路層沒有足夠的內存來進行寫操作，這時候就會出現寫不成功的情況，阻塞情況下會盡可能(有可能被中斷)等待到數據全部發送完畢， 對於非阻塞的情況就是一次寫多少算多少,沒有中斷的情況下也還是會出現write 到一部分的情況.