一、tcp和udp的區別 1javascript
二、tcp鏈接創建的時候3次握手，斷開鏈接的4次握手的具體過程 1css
三、什麼是同步？什麼是異步？ 2html
四、.什麼是阻塞？什麼是非阻塞？ 5vue
五、什麼是阻塞IO？什麼是非阻塞IO？ 6java
六、什麼是同步IO？什麼是異步IO？ 7node
七、 IO模型有幾種？分別是什麼？ 8linux
八、 Reactor和Proactor IO設計模式是什麼？ 13android
九、Java NIO 中的Buffer是什麼？如何使用？ 16web
十、Nio buffer 的內部結構是什麼？ 17面試
十一、Java NIO 中的 Channel是什麼？有什麼特色？ 18
十二、Java NIO中的Selector是什麼？ 21
1三、簡單講一下文件IO中的Path和Files 22
1四、select、poll和epoll的區別 23
1五、網絡編程中設計併發服務器，使用多進程 與 多線程 ，請問有什麼區別？ 29
1五、網絡編程的通常步驟 29
1六、TCP的全稱是? 31
1七、UDP的全稱是? 31
1八、請說出TCP和UDP的區別? 31
1九、TCP爲何不是兩次鏈接？而是三次握手？ 33
20、說明socket是什麼？ 34
2一、爲何須要端口?端口是真實存在的仍是虛擬的概念? 35
2二、Java中，端口使用兩個字節表示，能夠表示多少個端口? UDP和TCP端口是各自獨立的嗎? 35
2三、URL類有什麼做用? 35
2四、基於TCP的Socket網絡編程的主要步驟是什麼？ 36
2五、【上機】寫出創建TCP服務器ServerSocket的代碼。並說明accept方法有什麼特色? 37
2六、【上機】寫出創建TCP客戶端Socket的代碼。並說明創建Socket後，經過什麼方法Socket得到流對象? 37
2七、基於UDP的Socket網絡編程的主要步驟是什麼？ 37
2八、【上機】使用UDP的方式，完成對象的傳遞。 38
2九、HTTPClient相關問題 39
30、NIO 和傳統 BIO區別是什麼？ 40
3一、Java NIO 的幾個核心組成部分是什麼？做用分別是什麼？ 41
3二、簡單說一下http協議？ 47
3三、http協議下客戶端請求報文是什麼？ 48
3四、描述一下http協議服務器響應報文有哪些？ 49
3五、HTTP協議中經常使用的請求方法有哪些 50
3六、常見的HTTP狀態碼有哪些 51
3七、HTTP 協議中content-type指的是什麼？ 55
3八、網絡傳輸協議本質和做用是什麼？ 65
3九、能夠實現一個簡單的網絡協議嗎？ 65
1、tcp和udp的區別
TCP：是面向鏈接的流傳輸控制協議，具備高可靠性，確保傳輸數據的正確性，有驗證重發機制，所以不會出現丟失或亂序。
UDP：是無鏈接的數據報服務，不對數據報進行檢查與修改，無須等待對方的應答，會出現分組丟失、重複、亂序，但具備較好的實時性，UDP段結構比TCP的段結構簡單，所以網絡開銷也小。
二、tcp鏈接創建的時候3次握手，斷開鏈接的4次握手的具體過程
- 創建鏈接採用的3次握手協議，具體是指：
l 第一次握手是客戶端connect鏈接到server
l 第二次server accept client的請求以後，向client端發送一個消息，至關於說我都準備好了，你鏈接上我了
l 第三次 就是client向server發送的，就是對第二次握手消息的確認。以後client和server就開始通信了。
2．斷開鏈接的4次握手,具體以下：
l 斷開鏈接的一端發送close請求是第一次握手
l 另一端接收到斷開鏈接的請求以後須要對close進行確認，發送一個消息，這是第二次握手
l 發送了確認消息以後還要向對端發送close消息，要關閉對對端的鏈接，這是第3次握手
l 而在最初發送斷開鏈接的一端接收到消息以後，進入到一個很重要的狀態time_wait狀態，這個狀態也是面試官常常問道的問題，最後一次握手是最初發送斷開鏈接的一端接收到消息以後。對消息的確認。
三、什麼是同步？什麼是異步？
同步：
若是有多個任務或者事件要發生，這些任務或者事件必須逐個地進行，一個事件或者任務的執行會致使整個流程的暫時等待，這些事件沒有辦法併發地執行；
異步：
若是有多個任務或者事件發生，這些事件能夠併發地執行，一個事件或者任務的執行不會致使整個流程的暫時等待。
這就是同步和異步。
舉個簡單的例子，假若有一個任務包括兩個子任務A和B，對於同步來講，當A在執行的過程當中，B只有等待，直至A執行完畢，B才能執行；而對於異步就是A和B能夠併發地執行，B沒必要等待A執行完畢以後再執行，這樣就不會因爲A的執行致使整個任務的暫時等待。
若是還不理解，能夠先看下面這2段代碼：
void fun1() {
}
void fun2() {
}
void function(){
fun1();
fun2()
.....
.....
}
這段代碼就是典型的同步，在方法function中，fun1在執行的過程當中會致使後續的fun2沒法執行，fun2必須等待fun1執行完畢才能夠執行。
接着看下面這段代碼：
void fun1() {
}
void fun2() {
}
void function(){
new Thread(){
public void run() {
fun1();
}
}.start();
new Thread(){
public void run() {
fun2();
}
}.start();
.....
.....
}
這段代碼是一種典型的異步，fun1的執行不會影響到fun2的執行，而且fun1和fun2的執行不會致使其後續的執行過程處於暫時的等待。
事實上，同步和異步是一個很是廣的概念，它們的重點在於多個任務和事件發生時，一個事件的發生或執行是否會致使整個流程的暫時等待。我以爲能夠將同步和異步與Java中的synchronized關鍵字聯繫起來進行類比。當多個線程同時訪問一個變量時，每一個線程訪問該變量就是一個事件，對於同步來講，就是這些線程必須逐個地來訪問該變量，一個線程在訪問該變量的過程當中，其餘線程必須等待；而對於異步來講，就是多個線程沒必要逐個地訪問該變量，能夠同時進行訪問。
同步和異步能夠表如今不少方面，可是記住其關鍵在於多個任務和事件發生時，一個事件的發生或執行是否會致使整個流程的暫時等待。通常來講，能夠經過多線程的方式來實現異步，可是千萬記住不要將多線程和異步畫上等號，異步只是宏觀上的一個模式，採用多線程來實現異步只是一種手段，而且經過多進程的方式也能夠實現異步。同步和異步着重點在於多個任務的執行過程當中，一個任務的執行是否會致使整個流程的暫時等待
四、.什麼是阻塞？什麼是非阻塞？
阻塞：
當某個事件或者任務在執行過程當中，它發出一個請求操做，可是因爲該請求操做須要的條件不知足，那麼就會一直在那等待，直至條件知足；
非阻塞：
當某個事件或者任務在執行過程當中，它發出一個請求操做，若是該請求操做須要的條件不知足，會當即返回一個標誌信息告知條件不知足，不會一直在那等待。
舉個簡單的例子：
假如我要讀取一個文件中的內容，若是此時文件中沒有內容可讀，對於同步來講就是會一直在那等待，直至文件中有內容可讀；而對於非阻塞來講，就會直接返回一個標誌信息告知文件中暫時無內容可讀。
阻塞和非阻塞着重點在於發出一個請求操做時，若是進行操做的條件不知足是否會返會一個標誌信息告知條件不知足。理解阻塞和非阻塞能夠同線程阻塞類比地理解，當一個線程進行一個請求操做時，若是條件不知足，則會被阻塞，即在那等待條件知足。
五、什麼是阻塞IO？什麼是非阻塞IO？
在瞭解阻塞IO和非阻塞IO以前，先看下一個具體的IO操做過程是怎麼進行的。
一般來講，IO操做包括：對硬盤的讀寫、對socket的讀寫以及外設的讀寫。
當用戶線程發起一個IO請求操做（本文以讀請求操做爲例），內核會去查看要讀取的數據是否就緒，對於阻塞IO來講，若是數據沒有就緒，則會一直在那等待，直到數據就緒；對於非阻塞IO來講，若是數據沒有就緒，則會返回一個標誌信息告知用戶線程當前要讀的數據沒有就緒。當數據就緒以後，便將數據拷貝到用戶線程，這樣才完成了一個完整的IO讀請求操做，也就是說一個完整的IO讀請求操做包括兩個階段：
1）查看數據是否就緒；
2）進行數據拷貝（內核將數據拷貝到用戶線程）。
那麼阻塞（blocking IO）和非阻塞（non-blocking IO）的區別就在於第一個階段，若是數據沒有就緒，在查看數據是否就緒的過程當中是一直等待，仍是直接返回一個標誌信息。
Java中傳統的IO都是阻塞IO，好比經過socket來讀數據，調用read()方法以後，若是數據沒有就緒，當前線程就會一直阻塞在read方法調用那裏，直到有數據才返回；
而若是是非阻塞IO的話，當數據沒有就緒，read()方法應該返回一個標誌信息，告知當前線程數據沒有就緒，而不是一直在那裏等待。
六、什麼是同步IO？什麼是異步IO？
咱們先來看一下同步IO和異步IO的定義，在《Unix網絡編程》一書中對同步IO和異步IO的定義是這樣的：
A synchronous I/O operation causes the requesting process to be blocked until that I/O operation completes.
An asynchronous I/O operation does not cause the requesting process to be blocked.
從字面的意思能夠看出：同步IO即 若是一個線程請求進行IO操做，在IO操做完成以前，該線程會被阻塞；而異步IO爲 若是一個線程請求進行IO操做，IO操做不會致使請求線程被阻塞。
事實上，同步IO和異步IO模型是針對用戶線程和內核的交互來講的：
對於同步IO：當用戶發出IO請求操做以後，若是數據沒有就緒，須要經過用戶線程或者內核不斷地去輪詢數據是否就緒，當數據就緒時，再將數據從內核拷貝到用戶線程；
而異步IO：只有IO請求操做的發出是由用戶線程來進行的，IO操做的兩個階段都是由內核自動完成，而後發送通知告知用戶線程IO操做已經完成。也就是說在異步IO中，不會對用戶線程產生任何阻塞。
這是同步IO和異步IO關鍵區別所在，同步IO和異步IO的關鍵區別反映在數據拷貝階段是由用戶線程完成仍是內核完成。因此說異步IO必需要有操做系統的底層支持。
注意同步IO和異步IO與阻塞IO和非阻塞IO是不一樣的兩組概念。
阻塞IO和非阻塞IO是反映在當用戶請求IO操做時，若是數據沒有就緒，是用戶線程一直等待數據就緒，仍是會收到一個標誌信息這一點上面的。
也就是說，阻塞IO和非阻塞IO是反映在IO操做的第一個階段，在查看數據是否就緒時是如何處理的。
七、 IO模型有幾種？分別是什麼？
在《Unix網絡編程》一書中提到了五種IO模型
分別是：阻塞IO、非阻塞IO、多路複用IO、信號驅動IO以及異步IO。
下面就分別來介紹一下這5種IO模型的異同。
1.阻塞IO模型
最傳統的一種IO模型，即在讀寫數據過程當中會發生阻塞現象。
當用戶線程發出IO請求以後，內核會去查看數據是否就緒，若是沒有就緒就會等待數據就緒，而用戶線程就會處於阻塞狀態，用戶線程交出CPU。當數據就緒以後，內核會將數據拷貝到用戶線程，並返回結果給用戶線程，用戶線程才解除block狀態。
典型的阻塞IO模型的例子爲：
data = socket.read();
若是數據沒有就緒，就會一直阻塞在read方法。
2.非阻塞IO模型
當用戶線程發起一個read操做後，並不須要等待，而是立刻就獲得了一個結果。若是結果是一個error時，它就知道數據尚未準備好，因而它能夠再次發送read操做。一旦內核中的數據準備好了，而且又再次收到了用戶線程的請求，那麼它立刻就將數據拷貝到了用戶線程，而後返回。
因此事實上，在非阻塞IO模型中，用戶線程須要不斷地詢問內核數據是否就緒，也就說非阻塞IO不會交出CPU，而會一直佔用CPU。
典型的非阻塞IO模型通常以下：
僞代碼
while(true){
new MyThread(socket)
}
class MyThread{
data = socket.read();
if(data!= error){
處理數據
break;
}
可是對於非阻塞IO就有一個很是嚴重的問題，在while循環中須要不斷地去詢問內核數據是否就緒，這樣會致使CPU佔用率很是高，所以通常狀況下不多使用while循環這種方式來讀取數據。
3.多路複用IO模型
多路複用IO模型是目前使用得比較多的模型。Java NIO實際上就是多路複用IO。
在多路複用IO模型中，會有一個線程不斷去輪詢多個socket的狀態，只有當socket真正有讀寫事件時，才真正調用實際的IO讀寫操做。由於在多路複用IO模型中，只須要使用一個線程就能夠管理多個socket，系統不須要創建新的進程或者線程，也沒必要維護這些線程和進程，而且只有在真正有socket讀寫事件進行時，纔會使用IO資源，因此它大大減小了資源佔用。
在Java NIO中，是經過selector.select()去查詢每一個通道是否有到達事件，若是沒有事件，則一直阻塞在那裏，所以這種方式會致使用戶線程的阻塞。
也許有朋友會說，我能夠採用 多線程+ 阻塞IO 達到相似的效果，可是因爲在多線程 + 阻塞IO 中，每一個socket對應一個線程，這樣會形成很大的資源佔用，而且尤爲是對於長鏈接來講，線程的資源一直不會釋放，若是後面陸續有不少鏈接的話，就會形成性能上的瓶頸。
而多路複用IO模式，經過一個線程就能夠管理多個socket，只有當socket真正有讀寫事件發生纔會佔用資源來進行實際的讀寫操做。所以，多路複用IO比較適合鏈接數比較多的狀況。
另外多路複用IO爲什麼比非阻塞IO模型的效率高是由於在非阻塞IO中，不斷地詢問socket狀態時經過用戶線程去進行的，而在多路複用IO中，輪詢每一個socket狀態是內核在進行的，這個效率要比用戶線程要高的多。
不過要注意的是，多路複用IO模型是經過輪詢的方式來檢測是否有事件到達，而且對到達的事件逐一進行響應。所以對於多路複用IO模型來講，一旦事件響應體很大，那麼就會致使後續的事件遲遲得不處處理，而且會影響新的事件輪詢。
4.信號驅動IO模型
在信號驅動IO模型中，當用戶線程發起一個IO請求操做，會給對應的socket註冊一個信號函數，而後用戶線程會繼續執行，當內核數據就緒時會發送一個信號給用戶線程，用戶線程接收到信號以後，便在信號函數中調用IO讀寫操做來進行實際的IO請求操做。
5.異步IO模型
異步IO模型纔是最理想的IO模型，在異步IO模型中，當用戶線程發起read操做以後，馬上就能夠開始去作其它的事。
而另外一方面，從內核的角度，當它受到一個asynchronous read以後，它會馬上返回，說明read請求已經成功發起了，所以不會對用戶線程產生任何block。
而後，內核會等待數據準備完成，而後將數據拷貝到用戶線程，當這一切都完成以後，內核會給用戶線程發送一個信號，告訴它read操做完成了。
也就說用戶線程徹底不須要實際的整個IO操做是如何進行的，只須要先發起一個請求，當接收內核返回的成功信號時表示IO操做已經完成，能夠直接去使用數據了。
也就說在異步IO模型中，IO操做的兩個階段都不會阻塞用戶線程，這兩個階段都是由內核自動完成，而後發送一個信號告知用戶線程操做已完成。
用戶線程中不須要再次調用IO函數進行具體的讀寫。
這點是和信號驅動模型有所不一樣的
在信號驅動模型中，當用戶線程接收到信號表示數據已經就緒，而後須要用戶線程調用IO函數進行實際的讀寫操做；而在異步IO模型中，收到信號表示IO操做已經完成，不須要再在用戶線程中調用iO函數進行實際的讀寫操做。
注意，異步IO是須要操做系統的底層支持，在Java 7中，提供了Asynchronous IO。也就是java中的AIO
前面四種IO模型實際上都屬於同步IO，只有最後一種是真正的異步IO，由於不管是多路複用IO仍是信號驅動模型，IO操做的第2個階段都會引發用戶線程阻塞，也就是內核進行數據拷貝的過程都會讓用戶線程阻塞。
八、 Reactor和Proactor IO設計模式是什麼？
在傳統的網絡服務設計模式中，有兩種比較經典的模式：一種是 多線程，一種是線程池。
對於多線程模式，也就說來了client，服務器就會新建一個線程來處理該client的讀寫事件，以下圖所示：
這種模式雖然處理起來簡單方便，可是因爲服務器爲每一個client的鏈接都採用一個線程去處理，使得資源佔用很是大。所以，當鏈接數量達到上限時，再有用戶請求鏈接，直接會致使資源瓶頸，嚴重的可能會直接致使服務器崩潰。
所以，爲了解決這種一個線程對應一個客戶端模式帶來的問題，提出了採用線程池的方式，也就說建立一個固定大小的線程池，來一個客戶端，就從線程池取一個空閒線程來處理，當客戶端處理完讀寫操做以後，就交出對線程的佔用。所以這樣就避免爲每個客戶端都要建立線程帶來的資源浪費，使得線程能夠重用。
可是線程池也有它的弊端，若是鏈接大可能是長鏈接，所以可能會致使在一段時間內，線程池中的線程都被佔用，那麼當再有用戶請求鏈接時，因爲沒有可用的空閒線程來處理，就會致使客戶端鏈接失敗，從而影響用戶體驗。所以，線程池比較適合大量的短鏈接應用。
所以便出現了下面的兩種高性能IO設計模式：Reactor和Proactor。
在Reactor模式中，會先對每一個client註冊感興趣的事件，而後有一個線程專門去輪詢每一個client是否有事件發生，當有事件發生時，便順序處理每一個事件，當全部事件處理完以後，便再轉去繼續輪詢，以下圖所示：
多路複用IO就是採用Reactor模式。注意，上面的圖中展現的 是順序處理每一個事件，固然爲了提升事件處理速度，能夠經過多線程或者線程池的方式來處理事件。
在Proactor模式中，當檢測到有事件發生時，會新起一個異步操做，而後交由內核線程去處理，當內核線程完成IO操做以後，發送一個通知告知操做已完成，能夠得知，異步IO模型採用的就是Proactor模式。
9、Java NIO 中的Buffer是什麼？如何使用？
Buffer(緩衝區):
Java NIO Buffers用於和NIO Channel交互。 咱們從Channel中讀取數據到buffers裏，從Buffer把數據寫入到Channels；
Buffer本質上就是一塊內存區；
一個Buffer有三個屬性是必須掌握的，分別是：capacity容量、position位置、limit限制。
Buffer的常見方法
Buffer clear()
Buffer flip()
Buffer rewind()
Buffer position(int newPosition)
Buffer的使用方式/方法介紹:
分配緩衝區（Allocating a Buffer）:
ByteBuffer buf = ByteBuffer.allocate(28);//以ByteBuffer爲例子
寫入數據到緩衝區（Writing Data to a Buffer）
寫數據到Buffer有兩種方法：
1.從Channel中寫數據到Buffer
int bytesRead = inChannel.read(buf); //read into buffer.
2.經過put寫數據：
buf.put(127);
十、Nio buffer 的內部結構是什麼？
一個 buffer 主要由 position,limit,capacity 三個變量來控制讀寫的過程。此三個變量的含義見以下表格：
| 參數 |
寫模式 |
讀模式 |
| position |
當前寫入的單位數據數量。 |
當前讀取的單位數據位置。 |
| limit |
表明最多能寫多少單位數據和容量是同樣的。 |
表明最多能讀多少單位數據，和以前寫入的單位數據量一致。 |
| capacity |
buffer 容量 |
buffer 容量 |
Buffer 常見方法：
flip(): 寫模式轉換成讀模式
rewind() ：將 position 重置爲 0 ，通常用於重複讀。
clear() ：清空 buffer ，準備再次被寫入 (position 變成 0 ， limit 變成 capacity) 。
compact(): 將未讀取的數據拷貝到 buffer 的頭部位。
mark() 、 reset():mark 能夠標記一個位置， reset 能夠重置到該位置。
Buffer 常見類型： ByteBuffer 、 MappedByteBuffer 、 CharBuffer 、 DoubleBuffer 、 FloatBuffer 、 IntBuffer 、LongBuffer 、 ShortBuffer 。
channel 常見類型 :FileChannel 、 DatagramChannel(UDP) 、 SocketChannel(TCP) 、 ServerSocketChannel(TCP)
11、Java NIO 中的 Channel是什麼？有什麼特色？
Channel：
Java NIO中的SocketChannel是一個鏈接到TCP網絡套接字的通道。
能夠經過如下2種方式建立SocketChannel：
- 打開一個SocketChannel並鏈接到互聯網上的某臺服務器。
- 一個新鏈接到達ServerSocketChannel時，會建立一個SocketChannel。
打開 SocketChannel 下面是SocketChannel的打開方式：
SocketChannel socketChannel = SocketChannel.open();
socketChannel.connect(new InetSocketAddress("http://jenkov.com", 80));
關閉 SocketChannel
當用完SocketChannel以後調用SocketChannel.close()關閉SocketChannel： socketChannel.close();
從 SocketChannel 讀取數據
要從SocketChannel中讀取數據，調用一個read()的方法之一。
ByteBuffer buf = ByteBuffer.allocate(48);
int bytesRead = socketChannel.read(buf);
非阻塞模式
能夠設置 SocketChannel 爲非阻塞模式（non-blocking mode）.設置以後，就能夠在異步模式下調用connect(), read() 和write()了。
若是SocketChannel在非阻塞模式下，此時調用connect()，該方法可能在鏈接創建以前就返回了。爲了肯定鏈接是否創建，能夠調用finishConnect()的方法。
像這樣：
socketChannel.configureBlocking(false);
socketChannel.connect(new InetSocketAddress("http://jenkov.com", 80));
while(! socketChannel.finishConnect() ){
//wait, or do something else...
}
Java NIO Channel通道和流很是類似，主要有如下幾點區別：
l 通道能夠讀也能夠寫，流通常來講是單向的（只能讀或者寫，因此以前咱們用流進行IO操做的時候須要分別建立一個輸入流和一個輸出流）。
l 通道能夠異步讀寫。
l 通道老是基於緩衝區Buffer來讀寫。
Java NIO中最重要的幾個Channel的實現：
l FileChannel： 用於文件的數據讀寫
l DatagramChannel： 用於UDP的數據讀寫
l SocketChannel： 用於TCP的數據讀寫，通常是客戶端實現
l ServerSocketChannel: 容許咱們監聽TCP連接請求，每一個請求會建立會一個SocketChannel，通常是服務器實現
類層次結構
12、Java NIO中的Selector是什麼？
Selector（選擇器）：
Selector 通常稱 爲選擇器 ，固然你也能夠翻譯爲 多路複用器 。
它是Java NIO核心組件中的一個，用於檢查一個或多個NIO Channel（通道）的狀態是否處於可讀、可寫。
如此能夠實現單線程管理多個channels,也就是能夠管理多個網絡連接。
使用Selector的好處在於： 使用更少的線程來就能夠來處理通道了， 相比使用多個線程，避免了線程上下文切換帶來的開銷。
Selector（選擇器）的使用方法介紹
Selector的建立
Selector selector = Selector.open();
註冊Channel到Selector(Channel必須是非阻塞的)
channel.configureBlocking(false);
SelectionKey key = channel.register(selector, Selectionkey.OP_READ);
SelectionKey介紹
一個SelectionKey鍵表示了一個特定的通道對象和一個特定的選擇器對象之間的註冊關係。
從Selector中選擇channel(Selecting Channels via a Selector)
選擇器維護註冊過的通道的集合，而且這種註冊關係都被封裝在SelectionKey當中.
中止選擇的方法
wakeup()方法 和close()方法。
13、簡單講一下文件IO中的Path和Files
文件I/O基石：Path：
建立一個Path
File和Path之間的轉換，File和URI之間的轉換
獲取Path的相關信息
移除Path中的冗餘項
Files類：
Files.exists() 檢測文件路徑是否存在
Files.createFile() 建立文件
Files.createDirectories()和Files.createDirectory()建立文件夾
Files.delete()方法 能夠刪除一個文件或目錄
Files.copy()方法能夠吧一個文件從一個地址複製到另外一個位置
獲取文件屬性
遍歷一個文件夾
Files.walkFileTree()遍歷整個目錄
1四、select、poll和epoll的區別
在linux 沒有實現epoll事件驅動機制以前，咱們通常選擇用select或者poll等IO多路複用的方法來實現併發服務程序。在大數據、高併發、集羣等一些名詞唱得火熱之年代，select和poll的用武之地愈來愈有限，風頭已經被epoll佔盡。
select的缺點：
- 單個進程可以監視的文件描述符的數量存在最大限制，一般是1024，固然能夠更改數量，但因爲select採用輪詢的方式掃描文件描述符，文件描述符數量越多，性能越差；
在linux內核頭文件中，有這樣的定義：
#define __FD_SETSIZE 1024
- 內核 / 用戶空間內存拷貝問題，select須要複製大量的句柄數據結構，產生巨大的開銷；
- select返回的是含有整個句柄的數組，應用程序須要遍歷整個數組才能發現哪些句柄發生了事件；
- select的觸發方式是水平觸發，應用程序若是沒有完成對一個已經就緒的文件描述符進行IO操做，那麼以後每次select調用仍是會將這些文件描述符通知進程。
相比select模型，poll使用鏈表保存文件描述符，所以沒有了監視文件數量的限制，但其餘三個缺點依然存在。
拿select模型爲例，假設咱們的服務器須要支持100萬的併發鏈接，則在__FD_SETSIZE 爲1024的狀況下，則咱們至少須要開闢1k個進程才能實現100萬的併發鏈接。
除了進程間上下文切換的時間消耗外，從內核/用戶空間大量的無腦內存拷貝、數組輪詢等，是系統難以承受的。
所以，基於select模型的服務器程序，要達到10萬級別的併發訪問，是一個很難完成的任務。
epoll的實現機制與select/poll機制徹底不一樣，上面所說的 select的缺點在epoll上不復存在。
設想一下以下場景：
有100萬個客戶端同時與一個服務器進程保持着TCP鏈接。而每一時刻，一般只有幾百上千個TCP鏈接是活躍的(事實上大部分場景都是這種狀況)。如何實現這樣的高併發？
在select/poll時代，服務器進程每次都把這100萬個鏈接告訴操做系統(從用戶態複製句柄數據結構到內核態)，讓操做系統內核去查詢這些套接字上是否有事件發生，輪詢完後，再將句柄數據複製到用戶態，讓服務器應用程序輪詢處理已發生的網絡事件，這一過程資源消耗較大，所以，select/poll通常只能處理幾千的併發鏈接。
epoll的設計和實現與select徹底不一樣。
epoll經過在Linux內核中申請一個簡易的文件系統
(文件系統通常用什麼數據結構實現？B+樹)
把原先的select/poll調用分紅了3個部分：
1）調用epoll_create()創建一個epoll對象(在epoll文件系統中爲這個句柄對象分配資源)
2）調用epoll_ctl向epoll對象中添加這100萬個鏈接的套接字
3）調用epoll_wait收集發生的事件的鏈接
如此一來，要實現上面說是的場景，只須要在進程啓動時創建一個epoll對象，而後在須要的時候向這個epoll對象中添加或者刪除鏈接。同時，epoll_wait的效率也很是高，由於調用epoll_wait時，並無一股腦的向操做系統複製這100萬個鏈接的句柄數據，內核也不須要去遍歷所有的鏈接。
下面來看看Linux內核具體的epoll機制實現思路。
當某一進程調用epoll_create方法時，Linux內核會建立一個eventpoll結構體，這個結構體中有兩個成員與epoll的使用方式密切相關。eventpoll結構體以下所示：
struct eventpoll{
....
/*紅黑樹的根節點，這顆樹中存儲着全部添加到epoll中的須要監控的事件*/
struct rb_root rbr;
/*雙鏈表中則存放着將要經過epoll_wait返回給用戶的知足條件的事件*/
struct list_head rdlist;
....
};
每個epoll對象都有一個獨立的eventpoll結構體，用於存放經過epoll_ctl方法向epoll對象中添加進來的事件。這些事件都會掛載在紅黑樹中，如此，重複添加的事件就能夠經過紅黑樹而高效的識別出來(紅黑樹的插入時間效率是lgn，其中n爲樹的高度)。
而全部添加到epoll中的事件都會與設備(網卡)驅動程序創建回調關係，也就是說，當相應的事件發生時會調用這個回調方法。這個回調方法在內核中叫ep_poll_callback,它會將發生的事件添加到rdlist雙鏈表中。
在epoll中，對於每個事件，都會創建一個epitem結構體，以下所示：
struct epitem{
struct rb_node rbn;//紅黑樹節點
struct list_head rdllink;//雙向鏈表節點
struct epoll_filefd ffd; //事件句柄信息
struct eventpoll *ep; //指向其所屬的eventpoll對象
struct epoll_event event; //期待發生的事件類型
}
當調用epoll_wait檢查是否有事件發生時，只須要檢查eventpoll對象中的rdlist雙鏈表中是否有epitem元素便可。若是rdlist不爲空，則把發生的事件複製到用戶態，同時將事件數量返回給用戶。
經過紅黑樹和雙鏈表數據結構，並結合操做系統底層回調機制，造就了epoll的高效
epoll的用法
第一步：epoll_create()系統調用。此調用返回一個句柄，以後全部的使用都依靠這個句柄來標識。
第二步：epoll_ctl()系統調用。經過此調用向epoll對象中添加、刪除、修改感興趣的事件，返回0標識成功，返回-1表示失敗。
第三部：epoll_wait()系統調用。經過此調用收集收集在epoll監控中已經發生的事件。
1五、網絡編程中設計併發服務器，使用多進程 與 多線程 ，請問有什麼區別？
1，進程：
子進程是父進程的複製品。
子進程得到父進程數據空間、堆和棧的複製品。
2，線程：
相對與進程而言，線程是一個更加接近與執行體的概念，它能夠與同進程的其餘線程共享數據，但擁有本身的棧空間，擁有獨立的執行序列。
二者均可以提升程序的併發度，提升程序運行效率和響應時間。
線程和進程在使用上各有優缺點：
線程執行開銷小，但不利於資源管理和保護；而進程正相反。
同時，線程適合於在SMP機器上運行，而進程則能夠跨機器遷移。
SMP的全稱是"對稱多處理"（Symmetrical Multi-Processing）技術，是指在一個計算機上聚集了一組處理器(多CPU),各CPU之間共享內存子系統以及總線結構。
1五、網絡編程的通常步驟
對於TCP鏈接：
1.服務器端
1）建立套接字create；
2）綁定端口號bind；
3）監聽鏈接listen；
4）接受鏈接請求accept，並返回新的套接字；
5）用新返回的套接字recv/send；
6）關閉套接字。
2.客戶端
1）建立套接字create;
2）發起創建鏈接請求connect;
3）發送/接收數據send/recv；
4）關閉套接字。
TCP總結：
Server端：create – bind – listen– accept– recv/send– close
Client端：create——- conncet——send/recv——close.
對於UDP鏈接：
1.服務器端:
1）建立套接字create；
2）綁定端口號bind；
3）接收/發送消息recvfrom/sendto；
4）關閉套接字。
2.客戶端:
1）建立套接字create；
2）發送/接收消息sendto/recvfrom；
3）關閉套接字.
UDP總結:
Server端：create—-bind —-recvfrom/sendto—-close
Client端：create—- sendto/recvfrom—-close.
函數原型int recv( _In_ SOCKET s, _Out_ char *buf, _In_ int len, _In_ int flags);
16、TCP的全稱是?
Transfer Control Protocol。
17、UDP的全稱是?
User Datagram Protocol。
18、請說出TCP和UDP的區別?
TCP：
一種面向鏈接（鏈接導向）的、可靠的、基於字節流的傳輸層（Transport layer）通訊協議 。
特色：
面向鏈接；
點到點的通訊；
高可靠性；
佔用系統資源多、效率低；
UDP：
一種無鏈接的、提供面向事務的簡單不可靠信息傳送服務的傳輸層通訊協議。
特色:
非面向鏈接
傳輸不可靠，可能丟失
發送無論對方是否準備好，接收方收到也不確認
能夠廣播發送
很是簡單的協議，開銷小
TCP—傳輸控制協議,提供的是面向鏈接、可靠的字節流服務。當客戶和服務器彼此交換數據前，必須先在雙方之間創建一個TCP鏈接，以後才能傳輸數據。TCP提供超時重發，丟棄重複數據，檢驗數據，流量控制等功能，保證數據能從一端傳到另外一端。
UDP—用戶數據報協議，是一個簡單的面向數據報的運輸層協議。UDP不提供可靠性，它只是把應用程序傳給IP層的數據報發送出去，可是並不能保證它們能到達目的地。因爲UDP在傳輸數據報前不用在客戶和服務器之間創建一個鏈接，且沒有超時重發等機制，故而傳輸速度很快
19、TCP爲何不是兩次鏈接？而是三次握手？
若是A與B兩個進程通訊，若是僅是兩次鏈接。
可能出現的一種狀況
就是：A發送完請求報文之後，因爲網絡狀況很差，出現了網絡擁塞，即B延時很長時間後收到報文，即此時A將此報文認定爲失效的報文。
B收到報文後，會向A發起鏈接。此時兩次握手完畢
B會認爲已經創建了鏈接能夠通訊，B會一直等到A發送的鏈接請求
而A對失效的報文回覆天然不會處理。
所以會陷入B忙等的僵局，形成資源的浪費。
20、說明socket是什麼？
從上圖能夠看到：底層的東西已經被內核實現了，即咱們一般意義上的內核協議棧（傳輸層，網絡層，鏈路層）
最上面的Application（應用層）是咱們用戶所要實現的，它是屬於用戶進程的一部分，工做在用戶空間，那麼用戶空間的程序要想訪問內核，使用內核的服務，就須要一個接口，去訪問所須要的服務
對於網絡編程來講，這個接口就是套接口（Socket）。
Socket：能夠看做用戶進程和內核網絡協議棧編程（交互）接口
Socket：不只能夠在同一臺主機上進行通訊，也能夠在網絡上不一樣的主機間進行通訊，也能夠異構（軟硬件平臺不一樣）進行通訊（手機qq和PC機上的qq進行通訊，手機的系統是ARM，而PC機是x86）
21、爲何須要端口?端口是真實存在的仍是虛擬的概念?
IP地址用來標誌一臺計算機，可是一臺計算機上可能提供多種網絡應用程序，使用端口來區分這些應用程序。
端口是虛擬的概念，並非說在主機上真的有若干個端口。經過端口，能夠在一個主機上運行多個網絡應用程序。
端口範圍0---65535,16位整數。
22、Java中，端口使用兩個字節表示，能夠表示多少個端口? UDP和TCP端口是各自獨立的嗎?
端口範圍0---65535,16位整數。
因爲TCP/IP傳輸層的兩個協議TCP和UDP是徹底獨立的兩個軟件模塊，所以各自的端口號也相互獨立，如TCP有一個255號端口，UDP也能夠有一個255號端口，兩者並不衝突。
23、URL類有什麼做用?
URL：Uniform Resource Locator，統一資源定位器；俗稱「網址」，如：
"http://www.baidu.com:80/index.html#aa?cansu=bjsxt「
由4部分組成：
l 協議： http;
l 存放資源的主機域名：www.baidu.com;
l 端口號:80;
l 資源文件名: index.html#aa?cansu=bjsxt;
URL是指向互聯網「資源」的指針。資源能夠是簡單的文件或目錄，也能夠是對更爲複雜的對象的引用，例如對數據庫或搜索引擎的查詢。
24、基於TCP的Socket網絡編程的主要步驟是什麼？
基於TCP協議的Socket編程的主要步驟
服務器端（server）：
1. 構建一個ServerSocket實例，指定本地的端口。這個socket就是用來監聽指定端口的鏈接請求的。
2.重複以下幾個步驟：
a. 調用socket的accept()方法來得到下面客戶端的鏈接請求。經過accept()方法返回的socket實例，創建了一個和客戶端的新鏈接。
b.經過這個返回的socket實例獲取InputStream和OutputStream,能夠經過這兩個stream來分別讀和寫數據。
c.結束的時候調用socket實例的close()方法關閉socket鏈接。
客戶端（client）：
1.構建Socket實例，經過指定的遠程服務器地址和端口來創建鏈接。
2.經過Socket實例包含的InputStream和OutputStream來進行數據的讀寫。
3.操做結束後調用socket實例的close方法，關閉。
25、【上機】寫出創建TCP服務器ServerSocket的代碼。並說明accept方法有什麼特色?
//服務器監聽請求；
ServerSocket ss=new ServerSocket(9999);
//接受請求：建立了socket;
Socket socket=ss.accept();
詳見課上示例。
26、【上機】寫出創建TCP客戶端Socket的代碼。並說明創建Socket後，經過什麼方法Socket得到流對象?
//客戶端向服務器端發送請求；
Socket socket=new Socket("127.0.0.1",9999);
//建好鏈接後，開始傳輸數據；
OutputStream os=socket.getOutputStream();
詳見課上示例。
27、基於UDP的Socket網絡編程的主要步驟是什麼？
基於UDP協議的Socket編程的主要步驟
服務器端（server）：
1. 構造DatagramSocket實例，指定本地端口。
2. 經過DatagramSocket實例的receive方法接收DatagramPacket.DatagramPacket中間就包含了通訊的內容。
3. 經過DatagramSocket的send和receive方法來收和發DatagramPacket.
客戶端（client）：
1. 構造DatagramSocket實例。
2.經過DatagramSocket實例的send和receive方法發送DatagramPacket報文。
3.結束後，調用DatagramSocket的close方法關閉。
28、【上機】使用UDP的方式，完成對象的傳遞。
(1)客戶端向服務器端傳送對象信息；
DatagramSocket ds=new DatagramSocket(9999);
//構建數據包；
Scanner input=new Scanner(System.in);
System.out.println("請輸入用戶名：");
String username=input.nextLine();
System.out.println("請輸入密碼：");
String password=input.nextLine();
//事先要建立好User類；
User user=new User(username,password);
//字節流；在內存開闢緩衝區；
ByteArrayOutputStream baos=new ByteArrayOutputStream();
ObjectOutputStream oos=new ObjectOutputStream(baos);
oos.writeObject(user);
byte buf[]=baos.toByteArray();
DatagramPacket dp=new DatagramPacket(buf, buf.length, InetAddress.getByName("127.0.0.1"), 8888);//DatagramPacket只用byte[]數組;
//發送數據；
ds.send(dp);
(2)服務器端從客戶端接收對象信息；
//服務器定義DatagramSocket以接收數據；
DatagramSocket ds=new DatagramSocket(8888);
//定義一個數據包來接收數據；
//數據包裏是byte數組，因此還得定義一個byte數組；
byte buf[]=new byte[1024];
DatagramPacket dp=new DatagramPacket(buf, buf.length);
//接收客戶端發過來的數據；
ds.receive(dp);
//用字節流和對象流讀取對象信息；
ByteArrayInputStream bais=new ByteArrayInputStream(buf);
ObjectInputStream ois=new ObjectInputStream(bais);
User user=(User)ois.readObject();
System.out.println(user);
詳見課上示例。
29、HTTPClient相關問題
- 什麼是httpClient?
- 什麼是HttpClient不能作的?
- HttpClient有哪些特性？
- HttpClient怎樣發送帶參數的GET請求？
- HttpClient怎樣發送帶參數的POST請求？
- HttpClient怎樣獲取響應狀態？
- HttpClient怎樣獲取響應內容？
- HttpClient怎樣上傳文件？
30、NIO 和傳統 BIO區別是什麼？
NIO vs BIO之間的理念上面的區別（NIO將阻塞交給了後臺線程執行）
IO是面向流的，NIO是面向緩衝區的
Java BIO面向流意味着每次從流中讀一個或多個字節，直至讀取全部字節，它們沒有被緩存在任何地方；
NIO則能先後移動流中的數據，由於是面向緩衝區的 BIO流是阻塞的，NIO流是不阻塞的 Java IO的各類流是阻塞的。
這意味着，當一個線程調用read() 或 write()時，該線程被阻塞，直到有一些數據被讀取，或數據徹底寫入。
該線程在此期間不能再幹任何事情了 Java NIO的非阻塞模式，使一個線程從某通道發送請求讀取數據，可是它僅能獲得目前可用的數據，若是目前沒有數據可用時，就什麼都不會獲取。
NIO可以讓您只使用一個（或幾個）單線程管理多個通道（網絡鏈接或文件），但付出的代價是解析數據可能會比從一個阻塞流中讀取數據更復雜。
非阻塞寫也是如此。一個線程請求寫入一些數據到某通道，但不須要等待它徹底寫入，這個線程同時能夠去作別的事情。
選擇器
Java NIO的選擇器容許一個單獨的線程來監視多個輸入通道，你能夠註冊多個通道使用一個選擇器，而後使用一個單獨的線程來「選擇」通道：這些通道里已經有能夠處理的輸入，或者選擇已準備寫入的通道。這種選擇機制，使得一個單獨的線程很容易來管理多個通道。
31、Java NIO 的幾個核心組成部分是什麼？做用分別是什麼？
l Channels
l Buffers
l Selectors
基本上，全部的 IO 在NIO 中都從一個Channel 開始。
Channel 有點象流。
數據能夠從Channel讀到Buffer中，也能夠從Buffer 寫到Channel中。
Channel的實現：
（涵蓋了UDP 和 TCP 網絡IO，以及文件IO）
l FileChannel
l DatagramChannel
l SocketChannel
l ServerSocketChannel
讀數據：
int bytesRead = inChannel.read(buf);
寫數據：
int bytesWritten = inChannel.write(buf);
Buffer
Buffer實現： （byte, char、short, int, long, float, double ）
l ByteBuffer
l CharBuffer
l DoubleBuffer
l FloatBuffer
l IntBuffer
l LongBuffer
l ShortBuffer
Buffer使用
l 讀數據 flip()方法：
buf.flip();
將Buffer從寫模式切換到讀模式 調用flip()方法會將position設回0，並將limit設置成以前position的值。
l (char) buf.get()
讀取數據
l Buffer.rewind()
將position設回0，因此你能夠重讀Buffer中的全部數據 limit保持不變，仍然表示能從Buffer中讀取多少個元素（byte、char等）
l Buffer.mark()方法，
能夠標記Buffer中的一個特定position。
以後能夠經過調用 Buffer.reset()方法，恢復到Buffer.mark()標記時的position
一旦讀完了全部的數據，就須要清空緩衝區，讓它能夠再次被寫入。
l clear()方法：
清空整個緩衝區。 position將被設回0，limit被設置成 capacity的值
l compact()方法：
只會清除已經讀過的數據；任何未讀的數據都被移到緩衝區的起始處，新寫入的數據將放到緩衝區未讀數據的後面。
將position設到最後一個未讀元素正後面，limit被設置成 capacity的值 寫數據 buf.put(127);
Buffer的三個屬性
capacity：
l 表示容量
l Buffer的一個固定的大小值；
l Buffer滿了須要將其清空才能再寫；
l ByteBuffer.allocate(48)；該buffer的capacity爲48byte CharBuffer.allocate(1024);該buffer的capacity爲1024個char
position：
含義取決於Buffer處在讀模式仍是寫模式（初始值爲0，寫或者讀操做的當前位置）
寫數據時，初始的position值爲0；
其值最大可爲capacity-1
將Buffer從寫模式切換到讀模式，position會被重置爲0
limit：
含義取決於Buffer處在讀模式仍是寫模式（寫limit=capacity；讀limit等於最多能夠讀取到的數據）
寫模式下，limit等於Buffer的capacity 切換Buffer到讀模式時， limit表示你最多能讀到多少數據；
Selector
Selector容許單線程處理多個 Channel。
若是你的應用打開了多個鏈接（通道），但每一個鏈接的流量都很低，使用Selector就會很方便。
例如，在一個聊天服務器中。
要使用Selector，得向Selector註冊Channel，而後調用它的select()方法。這個方法會一直阻塞到某個註冊的通道有事件就緒。
一旦這個方法返回，線程就能夠處理這些事件，事件的例子有如新鏈接進來，數據接收等。
使用
建立：
Selector selector = Selector.open(); 註冊通道： channel.configureBlocking(false); //與Selector一塊兒使用時，Channel必須處於非阻塞模式
//這意味着不能將FileChannel與Selector一塊兒使用，由於FileChannel不能切換到非阻塞模式(而套接字通道均可以)
SelectionKey key = channel.register(selector, Selectionkey.OP_READ); //第二個參數代表Selector監聽Channel時對什麼事件感興趣
//SelectionKey.OP_CONNECT SelectionKey.OP_ACCEPT SelectionKey.OP_READ SelectionKey.OP_WRITE //能夠用或操做符將多個興趣組合一塊兒
SelectionKey 包含了interest集合 、ready集合 、Channel 、Selector 、附加的對象（可選）
int interestSet = key.interestOps()；
能夠進行相似interestSet & SelectionKey.OP_CONNECT的判斷
select()：
阻塞到至少有一個通道在你註冊的事件上就緒了
selectNow()：
不會阻塞，無論什麼通道就緒都馬上返回
selectedKeys()：
訪問「已選擇鍵集（selected key set）」中的就緒通道
close()：
使用完selector須要用其close()方法會關閉該Selector，且使註冊到該Selector上的全部SelectionKey實例無效
Set selectedKeys = selector.selectedKeys();
Iterator keyIterator = selectedKeys.iterator();
while(keyIterator.hasNext()) {
SelectionKey key = keyIterator.next();
if(key.isAcceptable()) {
// a connection was accepted by a ServerSocketChannel.
} else if (key.isConnectable()) {
// a connection was established with a remote server.
} else if (key.isReadable()) {
// a channel is ready for reading
} else if (key.isWritable()) {
// a channel is ready for writing
}
keyIterator.remove();//注意這裏必須手動remove；
代表該selectkey我已經處理過了；
}
32、簡單說一下http協議？
HTTP協議是Hyper Text Transfer Protocol（超文本傳輸協議）的縮寫,是用於從萬維網（WWW:World Wide Web ）服務器傳輸超文本到本地瀏覽器的傳送協議。
HTTP是一個基於TCP/IP通訊協議來傳遞數據（HTML 文件, 圖片文件, 查詢結果等）。
HTTP 工做原理
HTTP協議工做於客戶端-服務端架構上。瀏覽器做爲HTTP客戶端經過URL向HTTP服務端即WEB服務器發送全部請求。
Web服務器有：Apache服務器，Nginx，IIS服務器（Internet Information Services）等。
Web服務器根據接收到的請求後，向客戶端發送響應信息。
HTTP默認端口號爲80，可是你也能夠改成8080或者其餘端口。
HTTP三點注意事項：
l HTTP是無鏈接：無鏈接的含義是限制每次鏈接只處理一個請求。服務器處理完客戶的請求，並收到客戶的應答後，即斷開鏈接。採用這種方式能夠節省傳輸時間。
l HTTP是媒體獨立的：這意味着，只要客戶端和服務器知道如何處理的數據內容，任何類型的數據均可以經過HTTP發送。客戶端以及服務器指定使用適合的MIME-type內容類型。
l HTTP是無狀態：HTTP協議是無狀態協議。無狀態是指協議對於事務處理沒有記憶能力。缺乏狀態意味着若是後續處理須要前面的信息，則它必須重傳，這樣可能致使每次鏈接傳送的數據量增大。另外一方面，在服務器不須要先前信息時它的應答就較快。
33、http協議下客戶端請求報文是什麼？
客戶端發送一個HTTP請求到服務器的請求消息包括如下格式：
l 請求行（request line）
l 請求頭部（header）
l 空行
l 請求數據
四個部分組成
下圖給出了請求報文的通常格式。
客戶端請求：
GET /hello.txt HTTP/1.1
User-Agent: curl/7.16.3 libcurl/7.16.3 OpenSSL/0.9.7l zlib/1.2.3
Host: www.example.com
Accept-Language: en, mi
3四、描述一下http協議服務器響應報文有哪些？
HTTP響應也由四個部分組成，分別是：
l 狀態行
l 消息報頭
l 空行
l 響應正文
HTTP/1.1 200 OK
Date: Mon, 27 Jul 2009 12:28:53 GMT
Server: Apache
Last-Modified: Wed, 22 Jul 2009 19:15:56 GMT
ETag: "34aa387-d-1568eb00"
Accept-Ranges: bytes
Content-Length: 51
Vary: Accept-Encoding
Content-Type: text/plain
35、HTTP協議中經常使用的請求方法有哪些
根據HTTP標準，HTTP請求可使用多種請求方法。
HTTP1.0定義了三種請求方法： GET, POST 和 HEAD方法。
HTTP1.1新增了五種請求方法：OPTIONS, PUT, DELETE, TRACE 和 CONNECT 方法。
| 序號 |
方法 |
描述 |
| 1 |
GET |
請求指定的頁面信息，並返回實體主體。 |
| 2 |
HEAD |
相似於get請求，只不過返回的響應中沒有具體的內容，用於獲取報頭 |
| 3 |
POST |
向指定資源提交數據進行處理請求（例如提交表單或者上傳文件）。數據被包含在請求體中。 POST請求可能會致使新的資源的創建和/或已有資源的修改。 |
| 4 |
PUT |
從客戶端向服務器傳送的數據取代指定的文檔的內容。 |
| 5 |
DELETE |
請求服務器刪除指定的頁面。 |
| 6 |
CONNECT |
HTTP/1.1協議中預留給可以將鏈接改成管道方式的代理服務器。 |
| 7 |
OPTIONS |
容許客戶端查看服務器的性能。 |
| 8 |
TRACE |
回顯服務器收到的請求，主要用於測試或診斷。 |
36、常見的HTTP狀態碼有哪些
當瀏覽者訪問一個網頁時，瀏覽者的瀏覽器會向網頁所在服務器發出請求。當瀏覽器接收並顯示網頁前，此網頁所在的服務器會返回一個包含HTTP狀態碼的信息頭（server header）用以響應瀏覽器的請求。
HTTP狀態碼的英文爲HTTP Status Code。
下面是常見的HTTP狀態碼：
l 200 - 請求成功
l 301 - 資源（網頁等）被永久轉移到其它URL
l 404 - 請求的資源（網頁等）不存在
l 500 - 內部服務器錯誤
HTTP狀態碼由三個十進制數字組成，第一個十進制數字定義了狀態碼的類型，後兩個數字沒有分類的做用。HTTP狀態碼共分爲5種類型：
| HTTP狀態碼分類 |
|
| 分類 |
分類描述 |
| 1** |
信息，服務器收到請求，須要請求者繼續執行操做 |
| 2** |
成功，操做被成功接收並處理 |
| 3** |
重定向，須要進一步的操做以完成請求 |
| 4** |
客戶端錯誤，請求包含語法錯誤或沒法完成請求 |
| 5** |
服務器錯誤，服務器在處理請求的過程當中發生了錯誤 |
HTTP狀態碼列表:
| HTTP狀態碼列表 |
||
| 狀態碼 |
狀態碼英文名稱 |
中文描述 |
| 100 |
Continue |
繼續。客戶端應繼續其請求 |
| 101 |
Switching Protocols |
切換協議。服務器根據客戶端的請求切換協議。只能切換到更高級的協議，例如，切換到HTTP的新版本協議 |
|
|
||
| 200 |
OK |
請求成功。通常用於GET與POST請求 |
| 201 |
Created |
已建立。成功請求並建立了新的資源 |
| 202 |
Accepted |
已接受。已經接受請求，但未處理完成 |
| 203 |
Non-Authoritative Information |
非受權信息。請求成功。但返回的meta信息不在原始的服務器，而是一個副本 |
| 204 |
No Content |
無內容。服務器成功處理，但未返回內容。在未更新網頁的狀況下，可確保瀏覽器繼續顯示當前文檔 |
| 205 |
Reset Content |
重置內容。服務器處理成功，用戶終端（例如：瀏覽器）應重置文檔視圖。可經過此返回碼清除瀏覽器的表單域 |
| 206 |
Partial Content |
部份內容。服務器成功處理了部分GET請求 |
|
|
||
| 300 |
Multiple Choices |
多種選擇。請求的資源可包括多個位置，相應可返回一個資源特徵與地址的列表用於用戶終端（例如：瀏覽器）選擇 |
| 301 |
Moved Permanently |
永久移動。請求的資源已被永久的移動到新URI，返回信息會包括新的URI，瀏覽器會自動定向到新URI。從此任何新的請求都應使用新的URI代替 |
| 302 |
Found |
臨時移動。與301相似。但資源只是臨時被移動。客戶端應繼續使用原有URI |
| 303 |
See Other |
查看其它地址。與301相似。使用GET和POST請求查看 |
| 304 |
Not Modified |
未修改。所請求的資源未修改，服務器返回此狀態碼時，不會返回任何資源。客戶端一般會緩存訪問過的資源，經過提供一個頭信息指出客戶端但願只返回在指定日期以後修改的資源 |
| 305 |
Use Proxy |
使用代理。所請求的資源必須經過代理訪問 |
| 306 |
Unused |
已經被廢棄的HTTP狀態碼 |
| 307 |
Temporary Redirect |
臨時重定向。與302相似。使用GET請求重定向 |
|
|
||
| 400 |
Bad Request |
客戶端請求的語法錯誤，服務器沒法理解 |
| 401 |
Unauthorized |
請求要求用戶的身份認證 |
| 402 |
Payment Required |
保留，未來使用 |
| 403 |
Forbidden |
服務器理解請求客戶端的請求，可是拒絕執行此請求 |
| 404 |
Not Found |
服務器沒法根據客戶端的請求找到資源（網頁）。經過此代碼，網站設計人員可設置"您所請求的資源沒法找到"的個性頁面 |
| 405 |
Method Not Allowed |
客戶端請求中的方法被禁止 |
| 406 |
Not Acceptable |
服務器沒法根據客戶端請求的內容特性完成請求 |
| 407 |
Proxy Authentication Required |
請求要求代理的身份認證，與401相似，但請求者應當使用代理進行受權 |
| 408 |
Request Time-out |
服務器等待客戶端發送的請求時間過長，超時 |
| 409 |
Conflict |
服務器完成客戶端的PUT請求是可能返回此代碼，服務器處理請求時發生了衝突 |
| 410 |
Gone |
客戶端請求的資源已經不存在。410不一樣於404，若是資源之前有如今被永久刪除了可以使用410代碼，網站設計人員可經過301代碼指定資源的新位置 |
| 411 |
Length Required |
服務器沒法處理客戶端發送的不帶Content-Length的請求信息 |
| 412 |
Precondition Failed |
客戶端請求信息的先決條件錯誤 |
| 413 |
Request Entity Too Large |
因爲請求的實體過大，服務器沒法處理，所以拒絕請求。爲防止客戶端的連續請求，服務器可能會關閉鏈接。若是隻是服務器暫時沒法處理，則會包含一個Retry-After的響應信息 |
| 414 |
Request-URI Too Large |
請求的URI過長（URI一般爲網址），服務器沒法處理 |
| 415 |
Unsupported Media Type |
服務器沒法處理請求附帶的媒體格式 |
| 416 |
Requested range not satisfiable |
客戶端請求的範圍無效 |
| 417 |
Expectation Failed |
服務器沒法知足Expect的請求頭信息 |
|
|
||
| 500 |
Internal Server Error |
服務器內部錯誤，沒法完成請求 |
| 501 |
Not Implemented |
服務器不支持請求的功能，沒法完成請求 |
| 502 |
Bad Gateway |
充當網關或代理的服務器，從遠端服務器接收到了一個無效的請求 |
| 503 |
Service Unavailable |
因爲超載或系統維護，服務器暫時的沒法處理客戶端的請求。延時的長度可包含在服務器的Retry-After頭信息中 |
| 504 |
Gateway Time-out |
充當網關或代理的服務器，未及時從遠端服務器獲取請求 |
| 505 |
HTTP Version not supported |
服務器不支持請求的HTTP協議的版本，沒法完成處理 |
37、HTTP 協議中content-type指的是什麼？
Content-Type，內容類型，通常是指網頁中存在的Content-Type，用於定義網絡文件的類型和網頁的編碼，決定瀏覽器將以什麼形式、什麼編碼讀取這個文件，這就是常常看到一些Asp網頁點擊的結果倒是下載到的一個文件或一張圖片的緣由。
| 文件擴展名 |
Content-Type(Mime-Type) |
文件擴展名 |
Content-Type(Mime-Type) |
| .*（ 二進制流，不知道下載文件類型） |
application/octet-stream |
.tif |
image/tiff |
| .001 |
application/x-001 |
.301 |
application/x-301 |
| .323 |
text/h323 |
.906 |
application/x-906 |
| .907 |
drawing/907 |
.a11 |
application/x-a11 |
| .acp |
audio/x-mei-aac |
.ai |
application/postscript |
| .aif |
audio/aiff |
.aifc |
audio/aiff |
| .aiff |
audio/aiff |
.anv |
application/x-anv |
| .asa |
text/asa |
.asf |
video/x-ms-asf |
| .asp |
text/asp |
.asx |
video/x-ms-asf |
| .au |
audio/basic |
.avi |
video/avi |
| .awf |
application/vnd.adobe.workflow |
.biz |
text/xml |
| .bmp |
application/x-bmp |
.bot |
application/x-bot |
| .c4t |
application/x-c4t |
.c90 |
application/x-c90 |
| .cal |
application/x-cals |
.cat |
application/vnd.ms-pki.seccat |
| .cdf |
application/x-netcdf |
.cdr |
application/x-cdr |
| .cel |
application/x-cel |
.cer |
application/x-x509-ca-cert |
| .cg4 |
application/x-g4 |
.cgm |
application/x-cgm |
| .cit |
application/x-cit |
.class |
java/* |
| .cml |
text/xml |
.cmp |
application/x-cmp |
| .cmx |
application/x-cmx |
.cot |
application/x-cot |
| .crl |
application/pkix-crl |
.crt |
application/x-x509-ca-cert |
| .csi |
application/x-csi |
.css |
text/css |
| .cut |
application/x-cut |
.dbf |
application/x-dbf |
| .dbm |
application/x-dbm |
.dbx |
application/x-dbx |
| .dcd |
text/xml |
.dcx |
application/x-dcx |
| .der |
application/x-x509-ca-cert |
.dgn |
application/x-dgn |
| .dib |
application/x-dib |
.dll |
application/x-msdownload |
| .doc |
application/msword |
.dot |
application/msword |
| .drw |
application/x-drw |
.dtd |
text/xml |
| .dwf |
Model/vnd.dwf |
.dwf |
application/x-dwf |
| .dwg |
application/x-dwg |
.dxb |
application/x-dxb |
| .dxf |
application/x-dxf |
.edn |
application/vnd.adobe.edn |
| .emf |
application/x-emf |
.eml |
message/rfc822 |
| .ent |
text/xml |
.epi |
application/x-epi |
| .eps |
application/x-ps |
.eps |
application/postscript |
| .etd |
application/x-ebx |
.exe |
application/x-msdownload |
| .fax |
image/fax |
.fdf |
application/vnd.fdf |
| .fif |
application/fractals |
.fo |
text/xml |
| .frm |
application/x-frm |
.g4 |
application/x-g4 |
| .gbr |
application/x-gbr |
. |
application/x- |
| .gif |
image/gif |
.gl2 |
application/x-gl2 |
| .gp4 |
application/x-gp4 |
.hgl |
application/x-hgl |
| .hmr |
application/x-hmr |
.hpg |
application/x-hpgl |
| .hpl |
application/x-hpl |
.hqx |
application/mac-binhex40 |
| .hrf |
application/x-hrf |
.hta |
application/hta |
| .htc |
text/x-component |
.htm |
text/html |
| .html |
text/html |
.htt |
text/webviewhtml |
| .htx |
text/html |
.icb |
application/x-icb |
| .ico |
image/x-icon |
.ico |
application/x-ico |
| .iff |
application/x-iff |
.ig4 |
application/x-g4 |
| .igs |
application/x-igs |
.iii |
application/x-iphone |
| .img |
application/x-img |
.ins |
application/x-internet-signup |
| .isp |
application/x-internet-signup |
.IVF |
video/x-ivf |
| .java |
java/* |
.jfif |
image/jpeg |
| .jpe |
image/jpeg |
.jpe |
application/x-jpe |
| .jpeg |
image/jpeg |
.jpg |
image/jpeg |
| .jpg |
application/x-jpg |
.js |
application/x-javascript |
| .jsp |
text/html |
.la1 |
audio/x-liquid-file |
| .lar |
application/x-laplayer-reg |
.latex |
application/x-latex |
| .lavs |
audio/x-liquid-secure |
.lbm |
application/x-lbm |
| .lmsff |
audio/x-la-lms |
.ls |
application/x-javascript |
| .ltr |
application/x-ltr |
.m1v |
video/x-mpeg |
| .m2v |
video/x-mpeg |
.m3u |
audio/mpegurl |
| .m4e |
video/mpeg4 |
.mac |
application/x-mac |
| .man |
application/x-troff-man |
.math |
text/xml |
| .mdb |
application/msaccess |
.mdb |
application/x-mdb |
| .mfp |
application/x-shockwave-flash |
.mht |
message/rfc822 |
| .mhtml |
message/rfc822 |
.mi |
application/x-mi |
| .mid |
audio/mid |
.midi |
audio/mid |
| .mil |
application/x-mil |
.mml |
text/xml |
| .mnd |
audio/x-musicnet-download |
.mns |
audio/x-musicnet-stream |
| .mocha |
application/x-javascript |
.movie |
video/x-sgi-movie |
| .mp1 |
audio/mp1 |
.mp2 |
audio/mp2 |
| .mp2v |
video/mpeg |
.mp3 |
audio/mp3 |
| .mp4 |
video/mpeg4 |
.mpa |
video/x-mpg |
| .mpd |
application/vnd.ms-project |
.mpe |
video/x-mpeg |
| .mpeg |
video/mpg |
.mpg |
video/mpg |
| .mpga |
audio/rn-mpeg |
.mpp |
application/vnd.ms-project |
| .mps |
video/x-mpeg |
.mpt |
application/vnd.ms-project |
| .mpv |
video/mpg |
.mpv2 |
video/mpeg |
| .mpw |
application/vnd.ms-project |
.mpx |
application/vnd.ms-project |
| .mtx |
text/xml |
.mxp |
application/x-mmxp |
| .net |
image/pnetvue |
.nrf |
application/x-nrf |
| .nws |
message/rfc822 |
.odc |
text/x-ms-odc |
| .out |
application/x-out |
.p10 |
application/pkcs10 |
| .p12 |
application/x-pkcs12 |
.p7b |
application/x-pkcs7-certificates |
| .p7c |
application/pkcs7-mime |
.p7m |
application/pkcs7-mime |
| .p7r |
application/x-pkcs7-certreqresp |
.p7s |
application/pkcs7-signature |
| .pc5 |
application/x-pc5 |
.pci |
application/x-pci |
| .pcl |
application/x-pcl |
.pcx |
application/x-pcx |
| |
application/pdf |
|
application/pdf |
| .pdx |
application/vnd.adobe.pdx |
.pfx |
application/x-pkcs12 |
| .pgl |
application/x-pgl |
.pic |
application/x-pic |
| .pko |
application/vnd.ms-pki.pko |
.pl |
application/x-perl |
| .plg |
text/html |
.pls |
audio/scpls |
| .plt |
application/x-plt |
.png |
image/png |
| .png |
application/x-png |
.pot |
application/vnd.ms-powerpoint |
| .ppa |
application/vnd.ms-powerpoint |
.ppm |
application/x-ppm |
| .pps |
application/vnd.ms-powerpoint |
.ppt |
application/vnd.ms-powerpoint |
| .ppt |
application/x-ppt |
.pr |
application/x-pr |
| .prf |
application/pics-rules |
.prn |
application/x-prn |
| .prt |
application/x-prt |
.ps |
application/x-ps |
| .ps |
application/postscript |
.ptn |
application/x-ptn |
| .pwz |
application/vnd.ms-powerpoint |
.r3t |
text/vnd.rn-realtext3d |
| .ra |
audio/vnd.rn-realaudio |
.ram |
audio/x-pn-realaudio |
| .ras |
application/x-ras |
.rat |
application/rat-file |
| .rdf |
text/xml |
.rec |
application/vnd.rn-recording |
| .red |
application/x-red |
.rgb |
application/x-rgb |
| .rjs |
application/vnd.rn-realsystem-rjs |
.rjt |
application/vnd.rn-realsystem-rjt |
| .rlc |
application/x-rlc |
.rle |
application/x-rle |
| .rm |
application/vnd.rn-realmedia |
.rmf |
application/vnd.adobe.rmf |
| .rmi |
audio/mid |
.rmj |
application/vnd.rn-realsystem-rmj |
| .rmm |
audio/x-pn-realaudio |
.rmp |
application/vnd.rn-rn_music_package |
| .rms |
application/vnd.rn-realmedia-secure |
.rmvb |
application/vnd.rn-realmedia-vbr |
| .rmx |
application/vnd.rn-realsystem-rmx |
.rnx |
application/vnd.rn-realplayer |
| .rp |
image/vnd.rn-realpix |
.rpm |
audio/x-pn-realaudio-plugin |
| .rsml |
application/vnd.rn-rsml |
.rt |
text/vnd.rn-realtext |
| .rtf |
application/msword |
.rtf |
application/x-rtf |
| .rv |
video/vnd.rn-realvideo |
.sam |
application/x-sam |
| .sat |
application/x-sat |
.sdp |
application/sdp |
| .sdw |
application/x-sdw |
.sit |
application/x-stuffit |
| .slb |
application/x-slb |
.sld |
application/x-sld |
| .slk |
drawing/x-slk |
.smi |
application/smil |
| .smil |
application/smil |
.smk |
application/x-smk |
| .snd |
audio/basic |
.sol |
text/plain |
| .sor |
text/plain |
.spc |
application/x-pkcs7-certificates |
| .spl |
application/futuresplash |
.spp |
text/xml |
| .ssm |
application/streamingmedia |
.sst |
application/vnd.ms-pki.certstore |
| .stl |
application/vnd.ms-pki.stl |
.stm |
text/html |
| .sty |
application/x-sty |
.svg |
text/xml |
| .swf |
application/x-shockwave-flash |
.tdf |
application/x-tdf |
| .tg4 |
application/x-tg4 |
.tga |
application/x-tga |
| .tif |
image/tiff |
.tif |
application/x-tif |
| .tiff |
image/tiff |
.tld |
text/xml |
| .top |
drawing/x-top |
.torrent |
application/x-bittorrent |
| .tsd |
text/xml |
.txt |
text/plain |
| .uin |
application/x-icq |
.uls |
text/iuls |
| .vcf |
text/x-vcard |
.vda |
application/x-vda |
| .vdx |
application/vnd.visio |
.vml |
text/xml |
| .vpg |
application/x-vpeg005 |
.vsd |
application/vnd.visio |
| .vsd |
application/x-vsd |
.vss |
application/vnd.visio |
| .vst |
application/vnd.visio |
.vst |
application/x-vst |
| .vsw |
application/vnd.visio |
.vsx |
application/vnd.visio |
| .vtx |
application/vnd.visio |
.vxml |
text/xml |
| .wav |
audio/wav |
.wax |
audio/x-ms-wax |
| .wb1 |
application/x-wb1 |
.wb2 |
application/x-wb2 |
| .wb3 |
application/x-wb3 |
.wbmp |
image/vnd.wap.wbmp |
| .wiz |
application/msword |
.wk3 |
application/x-wk3 |
| .wk4 |
application/x-wk4 |
.wkq |
application/x-wkq |
| .wks |
application/x-wks |
.wm |
video/x-ms-wm |
| .wma |
audio/x-ms-wma |
.wmd |
application/x-ms-wmd |
| .wmf |
application/x-wmf |
.wml |
text/vnd.wap.wml |
| .wmv |
video/x-ms-wmv |
.wmx |
video/x-ms-wmx |
| .wmz |
application/x-ms-wmz |
.wp6 |
application/x-wp6 |
| .wpd |
application/x-wpd |
.wpg |
application/x-wpg |
| .wpl |
application/vnd.ms-wpl |
.wq1 |
application/x-wq1 |
| .wr1 |
application/x-wr1 |
.wri |
application/x-wri |
| .wrk |
application/x-wrk |
.ws |
application/x-ws |
| .ws2 |
application/x-ws |
.wsc |
text/scriptlet |
| .wsdl |
text/xml |
.wvx |
video/x-ms-wvx |
| .xdp |
application/vnd.adobe.xdp |
.xdr |
text/xml |
| .xfd |
application/vnd.adobe.xfd |
.xfdf |
application/vnd.adobe.xfdf |
| .xhtml |
text/html |
.xls |
application/vnd.ms-excel |
| .xls |
application/x-xls |
.xlw |
application/x-xlw |
| .xml |
text/xml |
.xpl |
audio/scpls |
| .xq |
text/xml |
.xql |
text/xml |
| .xquery |
text/xml |
.xsd |
text/xml |
| .xsl |
text/xml |
.xslt |
text/xml |
| .xwd |
application/x-xwd |
.x_b |
application/x-x_b |
| .sis |
application/vnd.symbian.install |
.sisx |
application/vnd.symbian.install |
| .x_t |
application/x-x_t |
.ipa |
application/vnd.iphone |
| .apk |
application/vnd.android.package-archive |
.xap |
application/x-silverlight-app |
38、網絡傳輸協議本質和做用是什麼？
協議本質是雙方約定好的一種傳輸規則，爲了讓傳輸數據的雙方節點能創建鏈接，按照約定去傳輸和解析數據