web項目中使用的協議

DNS協議

一、DNS協議的做用是將域名解析爲IP，網絡上的每一個站點的位置是用IP來肯定的，訪問一個網站首先就要知道它的IP，不過數據組成的IP記起來不方便，因此就使用域名來代替IP，因爲IP和域名的對應關係常常變化，因此就須要有專門將域名解析爲IP的服務器，咱們稱爲：DNS服務器。把域名發給DNS服務器，它就返回相應的IP。在window中可使用nslookup 或者ping 的命令查看DNS解析後的IP。

二、世界各地有不少DNS服務器，ISP（Internat服務提供商）會提供給咱們默認的DNS服務器。

TCP/IP協議

一、TCP和IP協議，一般會把他們放在一塊兒，其實他們是不一樣的兩種協議，做用也不同。

二、IP協議：是用來查找地址，對應網際互聯層，TCP協議：是用來規範傳輸規則的，對應的傳輸層。IP只負責找到地址，具體怎麼傳輸是由TCP來完成。相似送快遞，貨單上填寫的地址以及怎麼根據填寫的地址找到客戶，這至關於IP協議的功能。而具體怎麼將貨物送過去，最後讓客戶簽收簽字就至關於TCP協議。

三、TCP傳輸前會進行三次溝通，咱們稱爲"三次握手"，傳完數據斷開的時候進行四次溝通，咱們稱爲"四次揮手"。

四、TCP的兩個序號和三個標誌位的含義：

4.一、seq：sequence number的縮寫，表示所傳數據的序號。TCP傳輸時的每個字節都有一個序號，發送數據時會將數據的第一個序號發送給對方，接收方會根據序號check是否接收完整，不完整則會從新傳送。保證了數據的完整性。

4.二、ack：acknoledgement number縮寫，表示確認號。接收方用來給發送方反饋是否成功接收到數據信息，它的值爲但願接收的下一個數據包的起始序號

4.三、ACK：確認位，只有ACK=1的時候ack才起做用，正常通訊時ACK=1，第一次發起請求時，由於沒有須要確認接收的數據因此ACK爲0。

4.四、SYN：同步位，用於在創建鏈接時同步序號，剛開始創建鏈接時並無歷史接收的數據，因此ack也就沒辦法設置。SYN的做用就是，當接收端接收到SYN=1的報文時就會將ack設置位接收到的seq+1的值。SYN會在前兩次握手時都爲1，是由於通訊的雙方的ack都須要設置一個初始值；

4.五、FIN：終止位，用來在數據傳輸完畢後釋放鏈接。

五、三次握手流程：

第一次握手：客戶端向服務端發送SYN包，等待服務端響應，並進入SYN-SEND狀態

第二次握手：服務端收到SYN包，並肯定SYN=ACK+1,而後響應一個SYN包和ACK包。客戶端進入SYN-RECV狀態。

第三次握手：客戶端收到服務端SYN+ACK包。向服務器發送確認包ACK。發送完畢進入ESTABLISHED狀態。

六、四次揮手：

第一次揮手：主動關閉鏈接一方，發送FIN包。此時發送FIN包以前發送的數據若是沒有發送到。會進行重試發送。

第二次揮手：被動關閉一方收到FIN包。響應一個ACK包。

第三次揮手：被動關閉方發送一個FIN包。告訴被動關閉方。數據發送完畢。

第四次揮手：主動關閉方收到FIN包。發送一個ACK包給被動關閉方，至此四次揮手結束，斷開鏈接。

七、爲何創建鏈接須要三次握手呢？

兩次握手你們比較容易理解。第一次握手：客戶端發起鏈接請求到服務端。服務端收到請求後響應一個請求給客戶端，反饋給客戶端已接收到請求。能夠鏈接，正常理解這兩次握手就能夠了。爲何還要第三次呢？網絡具備不穩定性，假如客戶端發出去的第一個鏈接請求因爲某些緣由在網絡節點中滯留了致使延遲，客戶端發出第二個請求，而後成功與服務端創建鏈接，而後數據傳輸完畢，客戶端與服務端斷開鏈接。而這時第一個創建請求才到達服務端，其實這是一個早已失效的報文，可是此時服務端仍然認爲這是客戶端的創建鏈接請求第一次握手，因而服務端迴應了客戶端，第二次握手，若是隻有兩次握手，那麼到這裏，鏈接就創建了，可是其實客戶端並無任何數據要發送，形成很大的資源浪費。因此須要第三次握手，只有客戶端再次迴應一下，就能夠避免這種狀況。

HTTP協議

一、HTTP協議是應用層的協議，在TCP/IP協議接受到數據後須要經過HTTP協議來解析後才能使用。

二、HTTP中報文很重要，報文分請求報文和響應報文兩種類型，這兩種類型都包括三部分：首行，頭部，主體。請求報文的首行是請求行，包括方法（請求類型），URL和HTTP版本三項內容，響應請求的首行是狀態行，包括HTTP版本，狀態碼，剪短緣由其中緣由無關緊要。頭部保存一些鍵值對的屬性，用冒號分割。主體保存具體內容，請求報文中主要保存Post類型的參數，響應報文中保存頁面要顯示的結果。

三、請求報文中的方法有：GET、HEAD、POST、PUT、DELETE等

四、響應報文常見狀態碼：

4.一、1XX：信息性狀態碼。

4.二、2XX：成功狀態碼。如：200表示成功。

4.三、3XX：重定向狀態碼。如：301表示發生重定向。

4.四、4XX：客戶端錯誤狀態碼：如：404表示沒有找到請求的資源。

4.五、5XX：服務端錯誤狀態碼：如：500表示系統內部錯誤。

Servlet和JAVA WEB開發

經過TCP/IP協議和HTTP協議能夠獲得數據，Servlet的做用是對接受到的數據進行處理並生成要返回給客戶端的接口。Servlet指定了java處理WEB請求的標準和規範，咱們只需按照標準去作就OK了。但規範本身是不能幹活的，因此要想使用Servlet須要有相應的Servlet容器，常見的Tomcat就是一個Servlet容器。

 

郵件收發過程使用的協議（smtp,pop3協議）

https://www.cnblogs.com/panxuejun/p/10094152.html

 

Socket和Http之間的區別和概述

socket和http的區別：
Http協議：簡單的對象訪問協議，對應於應用層。Http協議是基於TCP連接的。
tcp協議：對應於傳輸層
ip協議：對應與網絡層
TCP/IP是傳輸層協議，主要解決數據如何在網絡中傳輸；而Http是應用層協議，主要解決如何包裝數據。

Socket是對TCP/IP協議的封裝，Socket自己並非協議，而是一個調用接口（API），經過Socket，咱們才能使用TCP/IP協議。

Http鏈接：http鏈接就是所謂的短鏈接，及客戶端向服務器發送一次請求，服務器端相應後鏈接即會斷掉。

socket鏈接：socket鏈接及時所謂的長鏈接，理論上客戶端和服務端一旦創建鏈接，則不會主動斷掉；可是因爲各類環境因素可能會是鏈接斷開，好比說：服務器端或客戶端主機down了，網絡故障，或者二者之間長時間沒有數據傳輸，網絡防火牆可能會斷開該連接已釋放網絡資源。因此當一個socket鏈接中沒有數據的傳輸，那麼爲了位置連續的鏈接須要發送心跳消息，具體心跳消息格式是開發者本身定義的。



1》TCP鏈接
手機可以使用聯網功能是由於手機底層實現了TCP/IP協議。可使手機終端經過無線網絡創建TCP鏈接，TCP協議能夠對上層網絡提供接口，使上層網絡數據的傳輸創建在無差異的網絡之上。
創建一個TCP鏈接須要三次握手：
第一次握手：客戶端發送sys包（syn=j）到服務器，並進入SYN_SEND狀態，等待服務器確認。
第二次握手：服務器收到syn包，必須確認客戶的SYN（ack=j+1）,同時本身也發送了一個SYN包（syn=k）,即SYN+ACK包，此時服務器進入SYN_RECV狀態。
第三次握手：客戶端收到服務器的SYN+ACK包，向服務器發送確認包ACK（ack=k+1），此包發送完畢，客戶端和服務器進入ESTABLISHED狀態，完成三次握手。

握手過程當中傳輸的暴力不含數據，三次握手完畢後，客戶端和服務端才正式開始傳送數據。理想狀態下，TCP鏈接一旦創建，在通訊雙方中任何一方主動關閉鏈接以前，TCP鏈接都將被一直保持下去，斷開鏈接時服務器和客戶端 都可以主動發起斷開TCP鏈接的請求，斷開過程須要通過「四次握手」（服務器 和客戶端交互，最終肯定斷開）

2》Http鏈接
Http協議即超文本傳輸協議，是Web聯網的基礎，也是手機聯網經常使用的協議之一，http協議是創建在TCP協議之上的一種應用。

Http鏈接最顯著的特色是客戶端發送的每次請求都須要服務器回送相應，在請求結束後，會主動釋放鏈接，從創建鏈接到關閉鏈接的過程稱之爲「一次鏈接」。
a》在HTTP1.0中。客戶端的每次請求都要創建一次單獨的鏈接，在處理完成請求後，就自動釋放鏈接。
b》在HTTP1.1中則能夠在依次鏈接中處理多個請求，而且多個請求能夠重疊進行，不須要等待一個請求結束後在發送下一個請求。
因爲Http在麼次請求結束以後都會主動釋放鏈接，所以HTTp協議鏈接是一種短鏈接，要保持客戶端程序的在線狀態，須要不斷的向服務器發起鏈接請求，一般的作法是即時不須要得到任何數據，客戶端也保持每隔一段固定的時間向服務器發送一次「保持鏈接」的請求，服務器在收到該請求後對客戶端進行回覆，代表知道客戶端「在線」，若服務器長時間沒法收到客戶端的請求，則認爲客戶端「下線」，若客戶端長時間沒法收到服務器的回覆，則認爲網絡已斷開。

3》socket原理
1）套接字（socket）概念
套接字（socket）是通訊的基石，是支持TCP/IP協議的網絡通訊的基本操做單元，他是網絡通訊過程當中端點的抽象表示，他包含網絡通訊必須的五種信息：鏈接使用的協議，本地主機的IP地址，本地進程的協議端口，遠程主機的IP地址，遠地進程的協議端口。

應用層經過傳輸層進行數據通訊時，TCP會遇到同時爲多個應用程序提供併發服務的問題，多個TCP鏈接多個應用程序進程可能須要經過同一個TCP協議端口傳輸數據，爲了區別不一樣的應用程序進程和鏈接，許多計算機操做系統爲應用程序與TCP/IP協議交互提供了套接字（socket）接口，應用層能夠和傳輸層經過socket接口區分來自於不一樣應用進程或網絡鏈接的通訊，實現數據傳輸的併發服務。
2）創建socket鏈接
創建socket鏈接至少須要一對套接字，其中一個運行於客戶端，稱爲ClientSocket，另外一個運行與服務器，稱爲ServerSocket。

套接字之間的鏈接分爲三個步驟：服務器監聽、客戶端請求、鏈接確認。

服務器監聽：服務端套接字並不定位具體的客戶端套接字，而是處於等待鏈接的狀態，實時監控網絡狀態，等待客戶端的鏈接請求。

客戶端請求：至客戶端的套接字提出鏈接請求，要練級的目標是服務器端的套接字，爲此客戶端的套接字必須首先描述他要鏈接的服務器的套接字，指出服務器端套接字的地址和端口號，而後向服務器端套接字提出鏈接請求。

鏈接確認：當服務器端套接字監聽到或者說接收到客戶端的套接字鏈接請求是，就響應客戶端套接字的請求，創建一個新的線程，把服務器端套接字的描述發給客戶端，一旦客戶端確認了此描述，雙方就正式連接連接，而服務器端 套接字繼續處於監聽狀態，繼續接受其餘客戶端套接字的鏈接請求。

4》socket鏈接與TCP鏈接
建立Socket鏈接時，能夠指定使用的傳輸層協議，socket能夠支持不一樣的傳輸層協議（TCP/UDP），當使用TCP協議進行鏈接時，該socket接連就是TCP連接.

一般狀況下Socket鏈接就是TCP鏈接，所以Socket鏈接一旦創建，通訊雙方便可開始相互發送數據內容，至到雙方鏈接斷開。但在實際網絡應用中，客戶端鏈接服務器之間的通訊每每須要穿越多箇中間節點，例如路由器，網關，防火牆等，大部分防火牆默認會關閉吃那個時間處於或活躍狀態的鏈接而致使的Socket鏈接斷連，所以須要輪詢告訴網絡，該連接處於活躍狀態。
erHTTp鏈接使用的是「請求一響應」的方式，不只在請求是須要先創建鏈接，並且須要客戶端向服務器發出請求後，服務端才能回覆數據。
不少狀況下，須要服務器端主動向客戶端推送數據，保持客戶端和服務器數據實時與同步，此時若雙方創建的是Socket鏈接，服務器就能夠直接將數據傳送給客戶端；若雙方創建的是HTTP鏈接，則須要等到客戶端發送一次請求後向服務端發送鏈接請求，不只能夠保持在線，同時也是在「詢問」服務器是否有新的數據，若是有就傳給客戶端。

文件傳輸協議FTP、SFTP和SCP

網絡通訊協議分層
應用層：

HTTP（Hypertext Transfer Protocol 超文本傳輸協議，顯示網頁）
DNS（Domain Name System）
FTP（File Transfer Protocol）
SFTP（SSH File Transfer Protocol，和FTP不同）
SCP（Secure copy，based on SSH）
SSH （Secure Shell）
通訊層：

TCP（Transmission Control Protocol 三次握手傳輸協議）
UDP
網絡層：

IP（Internet Protocol）
ICMP（Internet Control Message Protocol，主要用於路由發送錯誤報告）
連接層：

MAC（media access control）

文件傳輸協議：

參考資料：http://desert3.iteye.com/blog/1684130
 
FTP（File Transfer Protocol）：是TCP/IP網絡上兩臺計算機傳送文件的協議，FTP是在TCP/IP網絡和INTERNET上最先使用的協議之一，它屬於網絡協議組的應用層。FTP客戶機能夠給服務器發出命令來下載文件，上載文件，建立或改變服務器上的目錄。相比於HTTP，FTP協議要複雜得多。複雜的緣由，是由於FTP協議要用到兩個TCP鏈接，一個是命令鏈路，用來在FTP客戶端與服務器之間傳遞命令；另外一個是數據鏈路，用來上傳或下載數據。FTP是基於TCP協議的，所以iptables防火牆設置中只須要放開指定端口（21 + PASV端口範圍）的TCP協議便可。 
FTP工做模式：
PORT（主動）方式的鏈接過程是：客戶端向服務器的FTP端口（默認是21）發送鏈接請求，服務器接受鏈接，創建一條命令鏈路。當須要傳送數據時，客戶端在命令鏈路上用PORT命令告訴服務器：「我打開了一個1024+的隨機端口，你過來鏈接我」。因而服務器從20端口向客戶端的1024+隨機端口發送鏈接請求，創建一條數據鏈路來傳送數據。
PASV（Passive被動）方式的鏈接過程是：客戶端向服務器的FTP端口（默認是21）發送鏈接請求，服務器接受鏈接，創建一條命令鏈路。當須要傳送數據時，服務器在命令鏈路上用PASV命令告訴客戶端：「我打開了一個1024+的隨機端口，你過來鏈接我」。因而客戶端向服務器的指定端口發送鏈接請求，創建一條數據鏈路來傳送數據。
PORT方式，服務器會主動鏈接客戶端的指定端口，那麼若是客戶端經過代理服務器連接到internet上的網絡的話，服務器端可能會鏈接不到客戶端本機指定的端口，或者被客戶端、代理服務器防火牆阻塞了鏈接，致使鏈接失敗。PASV方式，服務器端防火牆除了要放開21端口外，還要放開PASV配置指定的端口範圍。
 

SFTP（Secure File Transfer Protocol）：安全文件傳送協議。能夠爲傳輸文件提供一種安全的加密方法。SFTP與 FTP有着幾乎同樣的語法和功能。SFTP爲SSH的一部份，是一種傳輸文件到服務器的安全方式。在SSH軟件包中，已經包含了一個叫做SFTP(Secure File Transfer Protocol)的安全文件傳輸子系統，SFTP自己沒有單獨的守護進程，它必須使用sshd守護進程（端口號默認是22）來完成相應的鏈接操做，因此從某種意義上來講，SFTP並不像一個服務器程序，而更像是一個客戶端程序。SFTP一樣是使用加密傳輸認證信息和傳輸的數據，因此，使用SFTP是很是安全的。可是，因爲這種傳輸方式使用了加密/解密技術，因此傳輸效率比普通的FTP要低得多，若是您對網絡安全性要求更高時，可使用SFTP代替FTP。

View Code

登錄遠程主機：  
sftp user@host  
針對本機的命令都加上l:  
lcd，lpwd  
將本機文件上傳到遠程：  
put filename.txt [some/directory]  
將當前文件夾下的文件上傳到遠程：  
mput *.* // multiple  
下載遠程文件到本地:  
get filename.file [some/directory]  
下載目錄下全部遠程文件到本地：  
mget *.* [some/directory]  
幫助：  
?  
退出：  
bye/exit/quit

SCP（Secure Copy）：SCP就是Secure copy，是用來進行遠程文件複製的，而且整個複製過程是加密的。數據傳輸使用ssh，而且和使用和ssh相同的認證方式，提供相同的安全保證。 

拷貝本地文件到遠程：  
scp filename.txt user@host:some/directory  
拷貝本地文件到遠程，使用指定端口：  
scp -P 2234 filename.txt user@host:some/directory  
拷貝多個文件到遠程home：  
scp filename1.txt filename2.txt user@host:~  
拷貝遠程文件到本地：  
scp user@host:directory/filename.txt  /directory  
拷貝遠程文件夾到本地：  
scp -r user@host:directory/folder  .  
拷貝遠程文件到遠程：  
scp user@host1:directory/filename.txt  user@host1:directory

比較：
FTP 基於TCP來傳輸文件，明文傳輸用戶信息和數據。

SFTP 基於SSH來加密傳輸文件，可靠性高，可斷點續傳。

SCP 是基於SSH來加密拷貝文件，但要知道詳細目錄，不可斷點續傳。

 

第三方登陸——OAuth2.0協議

 

想不想在本身的產品中加入微信、QQ、新浪微博等第三方登陸的功能？知道這些功能使用的都是什麼技術嗎？答案就是「開放式受權」，英文簡稱爲「OAuth」。OAuth協議爲用戶資源的受權提供了一個安全、簡易、開放的標準。OAuth協議不會使第三方觸及到用戶的帳戶信息，第三方無需使用用戶的用戶名和密碼就能夠申請得到該用戶資源的受權完成登陸。

OAuth的工做原理以下：
step1:獲取Request Token
step2:獲取Access Token
step3:後續API訪問
step4:Refresh Token刷新Access Token

舉個例子：
用戶要登陸目標網站，使用本身的QQ號進行第三方登陸，這個流程能夠簡化爲下圖：

接下來，詳細解釋其中關鍵環節。

請求OAuth登陸頁：
目標網站請求騰訊QQ的登陸頁時使用的是Request Token URL，也就是未受權的令牌請求服務地址。目標網站使用的是帶有特定參數的URL。
這個特定參數其實就相似於app_id和app_key，由於有不少網站都使用了QQ第三方登陸的功能，這些特定參數就是QQ分配給各個使用方網站的使用受權標識，是QQ驗證使用方網站權限的依據。然而，這些參數還不止於此，還有另一個就是回調地址，也就是說，請求OAuth登陸頁除了要附帶受權標識，還要附帶回調地址，以便告訴QQ的OAuth服務器，用戶在登陸成功之後要跳轉到哪一個URL。

用戶使用第三方帳號登陸並受權
在用戶登陸成功之後，跳轉到目標網站指定的URL（回調地址）。在跳轉過程當中，URL還會加上一個參數，咱們命名爲code吧。code這個參數是加密過的字符串。在用戶本機請求帶有code參數的回調地址時，回調地址對應的服務端會接收code參數。當接收到code參數之後，按理說已經能夠確保用戶登陸成功了。但在這裏還有一個安全隱患：萬一code被中間人截獲，中間人冒充目標網站使用QQ的OAuth服務器提供的各類權限，那就出事了。所以，還須要一個步驟來避免這種狀況。咱們要保證code參數被合法的目標網站獲取到。

返回登陸結果
從上一個環節中，咱們能夠知道，回調地址（一般是目標網站）服務器在獲得了code參數之後，還不能認爲是用戶已經登陸成功了，只有在QQ的OAuth服務器返回登陸結果的時候才能認爲用戶登陸成功。那麼，接下來就會拼接一個新的URL用來訪問QQ的OAuth服務器，讓其返回一個登陸結果。這個新的URL其實就是User Request URL（用戶已受權的令牌請求服務地址）。新的URL中會包含3個參數：app_id、app_key、code。3個參數一塊兒傳送到QQ的OAuth服務器，OAuth服務器就能夠確認的確是目標網站本尊，code沒有被中間人截獲。
另外，還有一點要注意：code的存在時間很短，目標網站服務器必須在很短的時間內完成整個交互過程。爲何要這樣設計？若是有中間人截獲了code，他就必須在很短的時間內對code進行破解，並且還要去僞造一個URL。然而加密算法可不是鬧着玩的，code能讓你這麼簡單就破解了？因此，這個作法進一步確保了這個過程的安全性。code是一個生命週期很短，而且只能使用一次的加密字符串。

以上就是第三方登陸的基本交互過程，還有一個Access Token（用戶經過目標網站訪問OAuth接口的令牌）沒有說起，爲了方便理解，就不加在上述過程了，由於其做用主要在於讓已被OAuth服務器受權的目標網站可使用其它OAuth服務器提供的服務，好比：把本身喜歡的音樂分享到QQ空間。