一、基礎(chǔ)知識(shí)
1寿酌、TCP/IP協(xié)議族
- IP協(xié)議：網(wǎng)絡(luò)層協(xié)議胰苏，保證了計(jì)算機(jī)之間可以發(fā)送和接收數(shù)據(jù)。
- TCP協(xié)議：傳輸層協(xié)議醇疼，一種端到端的協(xié)議硕并，建立一個(gè)虛擬鏈路用于發(fā)送和接收數(shù)據(jù)，基于重發(fā)機(jī)制秧荆，提供可靠的通信連接倔毙。為了方便通信，將報(bào)文分割成多個(gè)報(bào)文段發(fā)送乙濒。
- UDP協(xié)議：傳輸層協(xié)議陕赃，一種無連接的協(xié)議，每個(gè)數(shù)據(jù)報(bào)都是一個(gè)獨(dú)立的信息颁股，包括完整的源地址或目的地址么库，它在網(wǎng)絡(luò)上以任何可能的路徑傳往目的地，因此能否到達(dá)目的地豌蟋，到達(dá)目的地的時(shí)間以及內(nèi)容的正確性都是不能被保證的廊散。
通信雙方一方作為服務(wù)器等待客戶提出請(qǐng)求并予以響應(yīng)∥嗥＃客戶則在需要服務(wù)時(shí)向服務(wù)器提出申請(qǐng)允睹。服務(wù)器一般作為守護(hù)進(jìn)程始終運(yùn)行，監(jiān)聽網(wǎng)絡(luò)端口幌氮，一旦有客戶請(qǐng)求缭受，就會(huì)啟動(dòng)一個(gè)服務(wù)進(jìn)程來響應(yīng)該客戶，同時(shí)自己繼續(xù)監(jiān)聽服務(wù)端口该互，使后來的客戶也能及時(shí)得到服務(wù)米者。一個(gè)socket（通常都是server socket）等待建立連接時(shí)，另一個(gè)socket可以要求進(jìn)行連接宇智，一旦這兩個(gè)socket連接起來蔓搞，它們就可以進(jìn)行雙向數(shù)據(jù)傳輸，雙方都可以進(jìn)行發(fā)送或接收操作随橘。
2喂分、TCP3次握手，4次揮手過程
2.1机蔗、建立連接協(xié)議（三次握手）
（1）客戶端發(fā)送一個(gè)帶SYN標(biāo)志的TCP報(bào)文到服務(wù)器蒲祈。（聽得到嗎甘萧？）
（2）服務(wù)端回應(yīng)客戶端的報(bào)文同時(shí)帶ACK（acknowledgement，確認(rèn)）標(biāo)志和SYN（synchronize）標(biāo)志梆掸。它表示對(duì)剛才客戶端SYN報(bào)文的回應(yīng)扬卷；同時(shí)又標(biāo)志SYN給客戶端，詢問客戶端是否準(zhǔn)備好進(jìn)行數(shù)據(jù)通訊酸钦。（聽得到怪得，你能聽到我嗎？）
（3）客戶必須再次回應(yīng)服務(wù)端一個(gè)ACK報(bào)文钝鸽。（聽到了汇恤，我們可以說話了）
為什么需要“三次握手”？
在謝希仁著《計(jì)算機(jī)網(wǎng)絡(luò)》第四版中講“三次握手”的目的是“為了防止已失效的連接請(qǐng)求報(bào)文段突然又傳送到了服務(wù)端拔恰，因而產(chǎn)生錯(cuò)誤”因谎。“已失效的連接請(qǐng)求報(bào)文段”的產(chǎn)生在這樣一種情況下：client發(fā)出的第一個(gè)連接請(qǐng)求報(bào)文段并沒有丟失颜懊，而是在某個(gè)網(wǎng)絡(luò)結(jié)點(diǎn)長(zhǎng)時(shí)間的滯留了财岔，以致延誤到連接釋放以后的某個(gè)時(shí)間才到達(dá)server。本來這是一個(gè)早已失效的報(bào)文段河爹。但server收到此失效的連接請(qǐng)求報(bào)文段后匠璧，就誤認(rèn)為是client再次發(fā)出的一個(gè)新的連接請(qǐng)求。于是就向client發(fā)出確認(rèn)報(bào)文段咸这，同意建立連接夷恍。假設(shè)不采用“三次握手”，那么只要server發(fā)出確認(rèn)媳维，新的連接就建立了酿雪。由于現(xiàn)在client并沒有發(fā)出建立連接的請(qǐng)求，因此不會(huì)理睬server的確認(rèn)侄刽，也不會(huì)向server發(fā)送數(shù)據(jù)指黎。但server卻以為新的運(yùn)輸連接已經(jīng)建立，并一直等待client發(fā)來數(shù)據(jù)州丹。這樣醋安，server的很多資源就白白浪費(fèi)掉了。采用“三次握手”的辦法可以防止上述現(xiàn)象發(fā)生墓毒。例如剛才那種情況吓揪，client不會(huì)向server的確認(rèn)發(fā)出確認(rèn)。server由于收不到確認(rèn)所计，就知道client并沒有要求建立連接磺芭。”醉箕。 主要目的防止server端一直等待钾腺，浪費(fèi)資源。
2.2讥裤、連接終止協(xié)議（四次揮手）
由于TCP連接是全雙工的放棒，因此每個(gè)方向都必須單獨(dú)進(jìn)行關(guān)閉。這原則是當(dāng)一方完成它的數(shù)據(jù)發(fā)送任務(wù)后就能發(fā)送一個(gè)FIN來終止這個(gè)方向的連接己英。收到一個(gè) FIN只意味著這一方向上沒有數(shù)據(jù)流動(dòng)间螟，一個(gè)TCP連接在收到一個(gè)FIN后仍能發(fā)送數(shù)據(jù)。首先進(jìn)行關(guān)閉的一方將執(zhí)行主動(dòng)關(guān)閉损肛，而另一方執(zhí)行被動(dòng)關(guān)閉厢破。
（1） TCP客戶端發(fā)送一個(gè)FIN，用來關(guān)閉客戶到服務(wù)器的數(shù)據(jù)傳送（報(bào)文段4）治拿。
（2） 服務(wù)器收到這個(gè)FIN摩泪，它發(fā)回一個(gè)ACK，確認(rèn)序號(hào)為收到的序號(hào)加1（報(bào)文段5）劫谅。和SYN一樣见坑，一個(gè)FIN將占用一個(gè)序號(hào)。
（3） 服務(wù)器關(guān)閉客戶端的連接捏检，發(fā)送一個(gè)FIN給客戶端（報(bào)文段6）荞驴。
（4） 客戶段發(fā)回ACK報(bào)文確認(rèn)，并將確認(rèn)序號(hào)設(shè)置為收到序號(hào)加1（報(bào)文段7）贯城。
為什么需要“四次揮手”熊楼？
那可能有人會(huì)有疑問，在tcp連接握手時(shí)為何ACK是和SYN一起發(fā)送能犯，這里ACK卻沒有和FIN一起發(fā)送呢鲫骗。原因是因?yàn)閠cp是全雙工模式，接收到FIN時(shí)意味將沒有數(shù)據(jù)再發(fā)來悲雳，但是還是可以繼續(xù)發(fā)送數(shù)據(jù)挎峦。
3、請(qǐng)求報(bào)文
3.1合瓢、請(qǐng)求行
由3部分組成坦胶，分別為：請(qǐng)求方法、URL以及協(xié)議版本晴楔，之間由空格分隔
請(qǐng)求方法：GET顿苇、HEAD、PUT税弃、POST等方法纪岁，但并不是所有的服務(wù)器都實(shí)現(xiàn)了所有的方法，部分方法即便支持则果，處于安全性的考慮也是不可用的
協(xié)議版本：常用HTTP/1.1
3.2幔翰、請(qǐng)求頭部
請(qǐng)求頭部為請(qǐng)求報(bào)文添加了一些附加信息漩氨，由“名/值”對(duì)組成，每行一對(duì)遗增，名和值之間使用冒號(hào)分隔
-
Host接受請(qǐng)求的服務(wù)器地址叫惊，可以是IP:端口號(hào)，也可以是域名 -
User-Agent發(fā)送請(qǐng)求的應(yīng)用程序名稱 -
Connection指定與連接相關(guān)的屬性做修，如Connection:Keep-Alive -
Accept-Charset通知服務(wù)端可以發(fā)送的編碼格式 -
Accept-Encoding通知服務(wù)端可以發(fā)送的數(shù)據(jù)壓縮格式 -
Accept-Language通知服務(wù)端可以發(fā)送的語言 -
Range正文的字節(jié)請(qǐng)求范圍霍狰，為斷點(diǎn)續(xù)傳和并行下載提供可能，返回狀態(tài)碼是206
請(qǐng)求頭部的最后會(huì)有一個(gè)空行饰及，表示請(qǐng)求頭部結(jié)束蔗坯，接下來為請(qǐng)求正文，這一行非常重要燎含，必不可少
3.3宾濒、請(qǐng)求正文
可選部分，比如GET請(qǐng)求就沒有請(qǐng)求正文
4瘫镇、響應(yīng)報(bào)文
由3部分組成鼎兽，分別為：協(xié)議版本，狀態(tài)碼铣除，狀態(tài)碼描述谚咬，之間由空格分隔
狀態(tài)碼：為3位數(shù)字，2XX表示成功尚粘，3XX表示資源重定向择卦，4XX表示客戶端請(qǐng)求出錯(cuò)，5XX表示服務(wù)端出錯(cuò)
206狀態(tài)碼表示的是：客戶端通過發(fā)送范圍請(qǐng)求頭Range抓取到了資源的部分?jǐn)?shù)據(jù)郎嫁，得服務(wù)端提供支持
4.1秉继、響應(yīng)頭部
-
Server服務(wù)器應(yīng)用程序軟件的名稱和版本 -
Content-Type響應(yīng)正文的類型（是圖片還是二進(jìn)制字符串） -
Content-Length響應(yīng)正文長(zhǎng)度 -
Content-Charset響應(yīng)正文使用的編碼 -
Content-Encoding響應(yīng)正文使用的數(shù)據(jù)壓縮格式 -
Content-Language響應(yīng)正文使用的語言 -
Content-Range正文的字節(jié)位置范圍 -
Accept-Rangesbytes：表明服務(wù)器支持Range請(qǐng)求，單位是字節(jié)泽铛；none：不支持
正文的內(nèi)容可以用gzip等進(jìn)行壓縮尚辑，以提升傳輸速率
5、http協(xié)議中的多部分對(duì)象
報(bào)文的主體內(nèi)可以包含多部分對(duì)象盔腔，通常用來發(fā)送圖片杠茬、文件或表單等。
5.1弛随、multipart/form-data
Connection: keep-alive
Content-Length: 123
X-Requested-With: ShockwaveFlash/16.0.0.296
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/40.0.2214.93 Safari/537.36
Content-Type: multipart/form-data; boundary=Ij5ei4KM7KM7ae0KM7cH2ae0Ij5Ef1
Accept: */*
Accept-Encoding: gzip, deflate
Accept-Language: zh-CN,zh;q=0.8
Range: bytes=0-1024
Cookie: bdshare_firstime=1409052493497
--Ij5ei4KM7KM7ae0KM7cH2ae0Ij5Ef1
Content-Disposition: form-data; name="position"
1425264476444
--Ij5ei4KM7KM7ae0KM7cH2ae0Ij5Ef1
Content-Disposition: form-data; name="pics"; filename="file1.txt"
Content-Type: text/plain
...(file1.txt的數(shù)據(jù))...
ue_con_1425264252856
--Ij5ei4KM7KM7ae0KM7cH2ae0Ij5Ef1
Content-Disposition: form-data; name="cm"
100672
--Ij5ei4KM7KM7ae0KM7cH2ae0Ij5Ef1--
a）在請(qǐng)求頭中Content-Type: multipart/form-data; boundary=Ij5ei4KM7KM7ae0KM7cH2ae0Ij5Ef1是必須的瓢喉，boundary字符串可以隨意指定
b）上面有3個(gè)部分，分別用--boundary進(jìn)行分隔舀透。Content-Disposition: form-data; name="參數(shù)的名稱" + "\r\n" + "\r\n" + 參數(shù)值
c）--boundary-- 作為結(jié)束
二栓票、Https
1、Http的缺點(diǎn)
- 通信使用明文愕够，內(nèi)容可能會(huì)被竊聽 —— 加密通信線路
- 不驗(yàn)證通信方走贪，可能遭遇偽裝 —— 證書
- 無法驗(yàn)證報(bào)文的完整性佛猛，可能已被篡改 —— 數(shù)字簽名
Http+加密+認(rèn)證+完整性保護(hù)=Https
Https就是身披SSL（Secure Socket Layer，安全套接層）協(xié)議這層外殼的Http厉斟。當(dāng)使用了SSL之后挚躯，Http先和SSL通信，SSL再和TCP通信擦秽。
SSL（secure sockets layer）：安全套接層，它是在上世紀(jì)90年代中期漩勤，由網(wǎng)景公司設(shè)計(jì)的感挥，為解決 HTTP 協(xié)議傳輸內(nèi)容會(huì)被偷窺（嗅探）和篡改等安全問題而設(shè)計(jì)的，到了1999年越败，SSL成為互聯(lián)網(wǎng)上的標(biāo)準(zhǔn)触幼，名稱改為TLS（transport layer security）：安全傳輸層協(xié)議，兩者可視為同一種東西的不同階段究飞。
2置谦、Https的工作原理
HTTPS在傳輸數(shù)據(jù)之前需要客戶端（瀏覽器）與服務(wù)端（網(wǎng)站）之間進(jìn)行一次握手，在握手過程中將確立雙方加密傳輸數(shù)據(jù)的密碼信息亿傅。TLS/SSL協(xié)議不僅僅是一套加密傳輸?shù)膮f(xié)議媒峡，更是一件經(jīng)過藝術(shù)家精心設(shè)計(jì)的藝術(shù)品，TLS/SSL中使用了非對(duì)稱加密葵擎，對(duì)稱加密以及HASH算法谅阿。握手過程的具體描述如下：
- 瀏覽器將自己支持的一套加密規(guī)則發(fā)送給網(wǎng)站。
- 網(wǎng)站從中選出一組加密算法與HASH算法酬滤，并將自己的身份信息以證書的形式發(fā)回給瀏覽器签餐。證書里面包含了網(wǎng)站地址，加密公鑰盯串，以及證書的頒發(fā)機(jī)構(gòu)等信息氯檐。
- 瀏覽器獲得網(wǎng)站證書之后瀏覽器要做以下工作：
a) 驗(yàn)證證書的合法性（頒發(fā)證書的機(jī)構(gòu)是否合法，證書中包含的網(wǎng)站地址是否與正在訪問的地址一致等）体捏，如果證書受信任冠摄，則瀏覽器欄里面會(huì)顯示一個(gè)小鎖頭，否則會(huì)給出證書不受信的提示译打。
b) 如果證書受信任耗拓，或者是用戶接受了不受信的證書，瀏覽器會(huì)生成一串隨機(jī)數(shù)的密碼奏司，并用證書中提供的公鑰加密乔询。
c) 使用約定好的HASH算法計(jì)算握手消息，并使用生成的隨機(jī)數(shù)對(duì)消息進(jìn)行加密韵洋，最后將之前生成的所有信息發(fā)送給網(wǎng)站竿刁。 - 網(wǎng)站接收瀏覽器發(fā)來的數(shù)據(jù)之后要做以下的操作：
a) 使用自己的私鑰將信息解密取出密碼黄锤，使用密碼解密瀏覽器發(fā)來的握手消息，并驗(yàn)證HASH是否與瀏覽器發(fā)來的一致食拜。
b) 使用密碼加密一段握手消息鸵熟，發(fā)送給瀏覽器验夯。 - 瀏覽器解密并計(jì)算握手消息的HASH躯肌，如果與服務(wù)端發(fā)來的HASH一致诸狭，此時(shí)握手過程結(jié)束蟆淀，之后所有的通信數(shù)據(jù)將由之前瀏覽器生成的隨機(jī)密碼并利用對(duì)稱加密算法進(jìn)行加密幌衣。
這里瀏覽器與網(wǎng)站互相發(fā)送加密的握手消息并驗(yàn)證砰盐，目的是為了保證雙方都獲得了一致的密碼外臂，并且可以正常的加密解密數(shù)據(jù)湿硝，為后續(xù)真正數(shù)據(jù)的傳輸做一次測(cè)試蚕捉。另外奏篙，HTTPS一般使用的加密與HASH算法如下：
- 非對(duì)稱加密算法：RSA，DSA/DSS
- 對(duì)稱加密算法：AES迫淹，RC4秘通，3DES
- HASH算法：MD5，SHA1敛熬，SHA256
HTTPS對(duì)應(yīng)的通信時(shí)序圖如下：
3肺稀、證書分類
SSL 證書大致分三類:
- 認(rèn)可的證書頒發(fā)機(jī)構(gòu)(如: VeriSign), 或這些機(jī)構(gòu)的下屬機(jī)構(gòu)頒發(fā)的證書.
- 沒有得到認(rèn)可的證書頒發(fā)機(jī)構(gòu)頒發(fā)的證書.
- 自簽名證書， 自己通過JDK自帶工具keytool去生成一個(gè)證書荸型，分為臨時(shí)性的(在開發(fā)階段使用)或在發(fā)布的產(chǎn)品中永久性使用的兩種.
只有第一種, 也就是那些被安卓系統(tǒng)認(rèn)可的機(jī)構(gòu)頒發(fā)的證書, 在使用過程中不會(huì)出現(xiàn)安全提示盹靴。對(duì)于向權(quán)威機(jī)構(gòu)（簡(jiǎn)稱CA，Certificate Authority）申請(qǐng)過證書的網(wǎng)絡(luò)地址,用OkHttp或者HttpsURLConnection都可以直接訪問 瑞妇，不需要做額外的事情 稿静。但是申請(qǐng)需要$$ （每年要交 100 到 500 美元不等的費(fèi)用）。
CA機(jī)構(gòu)頒發(fā)的證書有3種類型：
域名型SSL證書（DV SSL）：信任等級(jí)普通辕狰，只需驗(yàn)證網(wǎng)站的真實(shí)性便可頒發(fā)證書保護(hù)網(wǎng)站改备；
企業(yè)型SSL證書（OV SSL）：信任等級(jí)強(qiáng)，須要驗(yàn)證企業(yè)的身份蔓倍，審核嚴(yán)格悬钳，安全性更高；
增強(qiáng)型SSL證書（EV SSL）：信任等級(jí)最高偶翅，一般用于銀行證券等金融機(jī)構(gòu)默勾，審核嚴(yán)格，安全性最高聚谁，同時(shí)可以激活綠色網(wǎng)址欄母剥。
4、HTTPS協(xié)議和HTTP協(xié)議的區(qū)別：
- https協(xié)議需要到ca申請(qǐng)證書，一般免費(fèi)證書很少环疼，需要交費(fèi)习霹。
- http是超文本傳輸協(xié)議，信息是明文傳輸炫隶，https 則是具有安全性的ssl加密傳輸協(xié)議淋叶。
- http和https使用的是完全不同的連接方式用的端口也不一樣,前者是80,后者是443。
- http的連接很簡(jiǎn)單,是無狀態(tài)的 伪阶。
- HTTPS協(xié)議是由SSL+HTTP協(xié)議構(gòu)建的可進(jìn)行加密傳輸煞檩、身份認(rèn)證的網(wǎng)絡(luò)協(xié)議， 要比http協(xié)議安全望门。
