1. http是無狀態通信，http的請求方式有哪些，可以自己定義新的請求方式麼。
HTTP是無狀態的，它的底層協議是由狀態的TCP，但是HTTP的一次完整協議動作，裏面是使用有狀態的TCP協議來完成的。而每次協議動作之間沒有任何關係。例如：第7次請求HTTP協議包，並不知道，這個包是爲了什麼？它或許是因爲上次沒有請求成功而重傳，或許是上次的後續請求，或許是其他的，這些HTTP自身都不知道。
參考：https://blog.csdn.net/wu1991924/article/details/8548051
根據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 |
回顯服務器收到的請求，主要用於測試或診斷。 |
2. socket通信，以及長連接，分包，連接異常斷開的處理。
參考：http://www.jianshu.com/p/90348ef3f41e
http://www.cnblogs.com/fuchongjundream/p/3914696.html
3. socket通信模型的使用，AIO和NIO。
參考：https://blog.csdn.net/u014401141/article/details/54406195
https://blog.csdn.net/anxpp/article/details/51512200
4. socket框架netty的使用，以及NIO的實現原理，爲什麼是異步非阻塞。
Netty是一個高性能、異步事件驅動的NIO框架，基於JAVA NIO提供的API實現。它提供了對TCP、UDP和文件傳輸的支持，作爲一個異步NIO框架，Netty的所有IO操作都是異步非阻塞的，通過Future-Listener機制，用戶可以方便的主動獲取或者通過通知機制獲得IO操作結果。
Java NIO是在jdk1.4開始使用的，它既可以說成“新I/O”，也可以說成非阻塞式I/O。下面是java NIO的工作原理：
1. 由一個專門的線程來處理所有的 IO 事件，並負責分發。
2. 事件驅動機制：事件到的時候觸發，而不是同步的去監視事件。
3. 線程通訊：線程之間通過 wait,notify 等方式通訊。保證每次上下文切換都是有意義的。減少無謂的線程切換。
閱讀過一些資料之後，下面貼出我理解的java NIO的工作原理圖：
（注：每個線程的處理流程大概都是讀取數據、解碼、計算處理、編碼、發送響應。）
Java NIO的服務端只需啓動一個專門的線程來處理所有的 IO 事件，這種通信模型是怎麼實現的呢？呵呵，我們一起來探究它的奧祕吧。java NIO採用了雙向通道（channel）進行數據傳輸，而不是單向的流（stream），在通道上可以註冊我們感興趣的事件。一共有以下四種事件：
|
事件名 |
對應值 |
|
服務端接收客戶端連接事件 |
SelectionKey.OP_ACCEPT(16) |
|
客戶端連接服務端事件 |
SelectionKey.OP_CONNECT(8) |
|
讀事件 |
SelectionKey.OP_READ(1) |
|
寫事件 |
SelectionKey.OP_WRITE(4) |
服務端和客戶端各自維護一個管理通道的對象，我們稱之爲selector，該對象能檢測一個或多個通道 (channel) 上的事件。我們以服務端爲例，如果服務端的selector上註冊了讀事件，某時刻客戶端給服務端發送了一些數據，阻塞I/O這時會調用read()方法阻塞地讀取數據，而NIO的服務端會在selector中添加一個讀事件。服務端的處理線程會輪詢地訪問selector，如果訪問selector時發現有感興趣的事件到達，則處理這些事件，如果沒有感興趣的事件到達，則處理線程會一直阻塞直到感興趣的事件到達爲止。下面是我理解的java NIO的通信模型示意圖：
5. 同步和異步，阻塞和非阻塞。
“阻塞”與“非阻塞”與“同步”與“異步”不能簡單的從字面埋解，提供一個從分佈式系統角度的回答。
1. 同步與異步
同步和異步關注的是消息通信機制（synchronous communication/ asynchronous communication）
所謂同步，就是在發出一個調用時，在沒有得到結果之前，該調用就不返回。但是一旦調用遐回， 就得到返回值了。
換句話說，就是由調用者主動等待這個調用的結果。
而異步則是相反，調用在發出之後，這個調用就直接返回了，所以沒有返回結果。換句話說，當一 個異步過程調用發出後，調用者不會立刻得到結果。而是在調用發出後，被調用者通過狀態、通知來通知調用者，或通過回調函數處理這個調用。
典型的異步編程模型比如Node.js
舉個通俗的例子：
你打電話問書店老闆有沒有《分佈式系統》這本書，如果是同步通信機制，書店老闆會說，你稍等，“我查一下”，然後開始查啊查，等查好了 (可能是5秒，也可能是一天）告訴你結果（返回結果）。
而異步通信機制，書店老闆直接告訴你我查一下啊，查好了打電話給你，然後直接掛電話了(不返回結果）。然後查好了,他會主動打電話給你。在這裏老闆通過回電這神方式來回調。
2. 阻塞與非阻塞
阻塞和非阻塞關注的是程序在等待調用結果（消息，返回值）時的扶態。
阻塞調用是指調用結果返回之前，當前線程會被掛起。調用線程只有在得到結果之後纔會返回。
非阻塞調用指在不能立刻得到結果之前，該調用不會阻塞當前線程。
還是上面的例子， 你打電話問書店老闆有沒有《分佈式系統》這本書，你如果是阻塞式調用，你會一直把自己掛起，直到得到這本書有沒有的結果，如果是非阻塞式調用，你不管老闆有沒有告訴你，你自己先一邊去玩 了，當然你也要偶爾過幾分鐘check—下老闆有沒有遐回結果。
在這裏阻塞與非阻塞與是否同步異步無關。跟老闆通過什麼方式回答你結果無關
6. OSI七層模型，包括TCP,IP的一些基本知識
1. OSI七層和TCP/IP四層的關係
1.1 OSI引入了服務、接口、協議、分層的概念，TCP/IP借鑑了OSI的這些概念建立TCP/IP模型。
1.2 OSI先有模型，後有協議，先有標準，後進行實踐；而TCP/IP則相反，先有協議和應用再提出了模型，且是參照的OSI模型。
1.3 OSI是一種理論下的模型，而TCP/IP已被廣泛使用，成爲網絡互聯事實上的標準。
TCP：transmission control protocol 傳輸控制協議
UDP：user data protocol 用戶數據報協議
|
OSI七層網絡模型 |
TCP/IP四層概念模型 |
對應網絡協議 |
|
應用層（Application） |
應用層 |
HTTP、TFTP, FTP, NFS, WAIS、SMTP |
|
表示層（Presentation） |
Telnet, Rlogin, SNMP, Gopher |
|
|
會話層（Session） |
SMTP, DNS |
|
|
傳輸層（Transport） |
傳輸層 |
TCP, UDP |
|
網絡層（Network） |
網絡層 |
IP, ICMP, ARP, RARP, AKP, UUCP |
|
數據鏈路層（Data Link） |
數據鏈路層 |
FDDI, Ethernet, Arpanet, PDN, SLIP, PPP |
|
物理層（Physical） |
IEEE 802.1A, IEEE 802.2到IEEE 802.11 |
參考：https://blog.csdn.net/guoguo527/article/details/52078962
7. http中，get post的區別
- GET在瀏覽器回退時是無害的，而POST會再次提交請求。
- GET產生的URL地址可以被Bookmark，而POST不可以。
- GET請求會被瀏覽器主動cache，而POST不會，除非手動設置。
- GET請求只能進行url編碼，而POST支持多種編碼方式。
- GET請求參數會被完整保留在瀏覽器歷史記錄裏，而POST中的參數不會被保留。
- GET請求在URL中傳送的參數是有長度限制的，而POST麼有。
- 對參數的數據類型，GET只接受ASCII字符，而POST沒有限制。
- GET比POST更不安全，因爲參數直接暴露在URL上，所以不能用來傳遞敏感信息。
- GET參數通過URL傳遞，POST放在Request body中。
GET和POST本質上沒有區別
GET和POST是什麼？HTTP協議中的兩種發送請求的方法。
HTTP是什麼？HTTP是基於TCP/IP的關於數據如何在萬維網中如何通信的協議。
HTTP的底層是TCP/IP。所以GET和POST的底層也是TCP/IP，也就是說，GET/POST都是TCP鏈接。GET和POST能做的事情是一樣一樣的。你要給GET加上request body，給POST帶上url參數，技術上是完全行的通的。
因此，GET和POST本質上就是TCP鏈接，並無差別。但是由於HTTP的規定和瀏覽器/服務器的限制，導致他們在應用過程中體現出一些不同。
GET和POST還有一個重大區別，簡單的說：
GET產生一個TCP數據包；POST產生兩個TCP數據包。
對於GET方式的請求，瀏覽器會把http header和data一併發送出去，服務器響應200（返回數據）；
而對於POST，瀏覽器先發送header，服務器響應100 continue，瀏覽器再發送data，服務器響應200 ok（返回數據）。
因爲POST需要兩步，時間上消耗的要多一點，看起來GET比POST更有效。因此Yahoo團隊有推薦用GET替換POST來優化網站性能。但這是一個坑！跳入需謹慎。爲什麼？
1. GET與POST都有自己的語義，不能隨便混用。
2. 據研究，在網絡環境好的情況下，發一次包的時間和發兩次包的時間差別基本可以無視。而在網絡環境差的情況下，兩次包的TCP在驗證數據包完整性上，有非常大的優點。
3. 並不是所有瀏覽器都會在POST中發送兩次包，Firefox就只發送一次。
8. 說說http,tcp,udp之間關係和區別。
TCP/IP是個協議組，可分爲四個層次：網絡接口層、網絡層、傳輸層和應用層。
在網絡層有IP協議、ICMP協議、ARP協議、RARP協議和BOOTP協議。
在傳輸層中有TCP協議與UDP協議。
在應用層有HTTP、FTP、TELNET、SMTP、DNS等協議。
TCP 傳送控制協議(Transmission Control Protocol)：
TCP是傳輸層的一個協議，基於IP協議，用來傳輸類似HTTP的信息。如果把IP協議類比爲一個“公路”的話，那TCP協議可以看成是在公路上行駛的“卡車”。TCP協議是面向連接的協議，通過三次握手機制，儘量保證連接的可靠性。tcp的鏈接需要進行三次握手，釋放連接需要四次揮手。
UDP 用戶數據報協議 （User Datagram Protocol） ：
UDP也是傳輸層的一個協議。但是與TCP不同的是，UDP不是面向連接的，並不保證傳輸的可靠性，沒有TCP的建立連接的三次握手機制，對於傳輸效率上面有了提升。
個人理解：
這個就比較簡單粗暴了，A要給B傳數據，然後就直接傳了。
HTTP 超文本傳輸協議（HyperText Transfer Protocal）：
HTTP是在應用層的一個協議，本身就是一個協議，是從Web服務器傳輸超文本到本地瀏覽器的傳輸協議。
HTTP協議基於請求\響應模型的，並且是基於TCP協議的。
HTTP連接最顯著的特點是客戶端發送的每次請求都需要服務器回送響應，在請求結束後，會主動釋放連接。從建立連接到關閉連接的過程稱爲“一次連接”。
9. 說說瀏覽器訪問www.taobao.com，經歷了怎樣的過程。
1、客戶端瀏覽器通過DNS解析到www.taobao.com的IP地址a，通過這個IP地址找到客戶端到服務器的路徑。客戶端瀏覽器發起一個HTTP會話到a，然後通過TCP進行封裝數據包，輸入到網絡層。
2、在客戶端的傳輸層，把HTTP會話請求分成報文段，添加源和目的端口，如服務器使用80端口監聽客戶端的請求，客戶端由系統隨機選擇一個端口如5000，與服務器進行交換，服務器把相應的請求返回給客戶端的5000端口。然後使用IP層的IP地址查找目的端。
3、客戶端的網絡層不用關係應用層或者傳輸層的東西，主要做的是通過查找路由表確定如何到達服務器，期間可能經過多個路由器，這些都是由路由器來完成的工作，我不作過多的描述，無非就是通過查找路由表決定通過那個路徑到達服務器。
4、客戶端的鏈路層，包通過鏈路層發送到路由器，通過鄰居協議查找給定IP地址的MAC地址，然後發送ARP請求查找目的地址，如果得到迴應後就可以使用ARP的請求應答交換的IP數據包現在就可以傳輸了，然後發送IP數據包到達服務器的地址。
參考：https://blog.csdn.net/DoUUnderstand/article/details/69761491
10. HTTP協議、 HTTPS協議，SSL協議及完整交互過程；
SSL
1.安全套接字（Secure Socket Layer，SSL）協議是Web瀏覽器與Web服務器之間安全交換信息的協議。
2.SSL協議的三個特性
Ø 保密：在握手協議中定義了會話密鑰後，所有的消息都被加密。
Ø 鑑別：可選的客戶端認證，和強制的服務器端認證。
Ø 完整性：傳送的消息包括消息完整性檢查（使用MAC）。
3.SSL的位置
HTTPS
1.HTTPS基於SSL的HTTP協議。
2.HTTPS使用與HTTP不同的端口(HTTP:80 ， HTTPS:443，一個加密、身份驗證層（HTTP與TCP之間）)。
3.提供了身份驗證與加密通信方法，被廣泛用於互聯網上安全敏感的通信。
交互過程
客戶端在使用HTTPS方式與Web服務器通信時有以下幾個步驟，如圖所示。
1) 客戶端請求建立SSL連接，並將自己支持的一套加密規則發送給網站。
2) 網站從中選出一組加密算法與HASH算法，並將自己的身份信息以證書的形式發回給瀏覽器。證書裏面包含了網站地址，加密公鑰，以及證書的頒發機構等信息
3) 獲得網站證書之後瀏覽器要做以下工作：
Ø 驗證證書的合法性
Ø 如果證書受信任，瀏覽器會生成一串隨機數的密碼，並用證書中提供的公鑰加密。
Ø 使用約定好的HASH計算握手消息，
Ø 使用生成的隨機數對消息進行加密，最後將之前生成的所有信息發送給網站。
4) 網站接收瀏覽器發來的數據之後要做以下的操作：
Ø 使用自己的私鑰將信息解密取出密碼
Ø 使用密碼解密瀏覽器發來的握手消息，並驗證HASH是否與瀏覽器發來的一致。
Ø 使用密碼加密一段握手消息，發送給瀏覽器
5) 瀏覽器解密並計算握手消息的HASH，如果與服務端發來的HASH一致，此時握手結束。
6) 使用隨機密碼和對稱加密算法對傳輸的數據加密，傳輸。
4. 加密與HASH算法如下：
1) 非對稱加密算法：RSA，DSA/DSS，用於在握手過程中加密生成的密碼。
2) 對稱加密算法：AES，RC4，3DES，用於對真正傳輸的數據進行加密。
3) HASH算法：MD5，SHA1，SHA256，驗證數據的完整性。
5. HTTP與HTTPS的區別：
1) https協議需要申請證書。
2) http是超文本傳輸協議，明文傳輸；https使用的是具有安全性的SSL加密傳輸協議。
3) http端口80,；https端口443。
4) http連接簡單無狀態；https由SSL+HTTP協議構件的可進行加密傳輸、身份驗證的網絡協議。
11. tcp的擁塞，快回傳，ip的報文丟棄
參考：https://blog.csdn.net/a386stf/article/details/80510045
12. https處理的一個過程，對稱加密和非對稱加密
參考問題10
13. head各個特點和區別
感覺問題有問題，估計是問http請求方法的區別，參考問題1