阻塞模式

在數據網和排隊的理論，網路堵塞發生當增加增量在被提供的裝載主角里或者只對在網路生產量的小增量，或對對網路生產量的實際減少。

使用進取的再試補償小包損失的網路協議傾向於保留系統在網路堵塞州在最初的裝載被減少了到通常不會導致網路堵塞的水平以後。因而，網路使用這些協議可能陳列二個穩定狀態在裝載之下的同樣水平。穩定狀態以低生產量知道當壅塞崩潰，由約翰·Nagle第一次定義了在RFC896,在1984年被寫的條款，當他辨認了有TCP網路協議的早期執行的問題在非常早期的網際網路的部份。壅塞崩潰是一個系統譬如數據網安定了在裝載之下入州交通需求是大量的情況但一點有用的生產量是可利用的，以高水平小包損失，延遲，並且延遲變異。

普遍壅塞崩潰的經驗在網際網路在1987導致了TCP壅塞控制機制的進一步改善。

現代網路使用壅塞控制和網路堵塞退避技術設法避免壅塞崩潰。這些包括指數backoff在協議譬如TCP和乙太網，和市場排隊在設備里譬如路由器

是socket的預設方式，也是最常用的方式，即函數阻塞直到調用完畢。可參見前面的例子。

可能造成阻塞的函數有：connect()、accept()、讀寫函數、select()、poll()、gethostbyname()等。

阻塞模式

程序調用可能造成阻塞的函數時，如果會發生阻塞，這些函數返回-1並將errno設置為EAGAIN或EWOULDBLOCK，程序可繼續向下運行。可能阻塞的函數對應的任務完成，則再次調用該函數時就返回0表示運行結束。

非阻塞模式可以避免程序死鎖，但是需要程序不斷檢查各個可能阻塞的函數的狀態，當一個應用程序使用了非阻塞模式的套接字，它需要使用一個循環來不聽的測試是否一個文件描述符有數據可讀（稱做polling）。應用程序不停的polling內核來檢查是否I/O操作已經就緒。這將是一個極浪費CPU資源的操作，因此不能實際應用。一般非阻塞模式是與同步I/O模式共同使用的。

非阻塞模式

I/O多路復用（同步I/O模式）

使用select()、poll()等函數實現對多個socket的同步I/O操作。它能同時等待多個socket描述符，而這些socket描述符其中的任意一個進入讀就緒/寫就緒/出錯狀態，select()函數就可以返回。請參見函數說明和程序

信號驅動I/O

非同步I/O