HTTP網絡協(xié)議（五）
15～18課
15.狀態(tài)碼_form提交
狀態(tài)碼（Status Code）
-狀態(tài)碼指示HTTP請求是否已成功完成
狀態(tài)碼可以分為5類
-信息響應：100～199
-成功響應：200～299
-重定向：300～399
-客戶端錯誤：400～499
-服務端錯誤：500～599
狀態(tài)碼描述語
100 continue
-請求的初始部分已經被服務器收到，并且沒有被服務器拒絕，客戶端應該繼續(xù)發(fā)送剩余的請求，如果請求已完成，就忽略這個響應
-允許客戶端發(fā)送帶請求體的請求前，判斷服務器是否愿意接收請求（服務器通過請求頭判斷）
-在某些情況下，如果服務器再不堪請求體就拒絕請求時，客戶端就發(fā)送請求體是不恰當的或低效的
200 OK：請求成功
302 Found：請求的資源被暫時的移動到了由Location頭部指定的URL上
304 Not Modified: 說明無需再次傳輸請求的內容，也就是說可以使用緩存的內容
400 Bad Request: 由于語法無效，服務器無法理解該請求
有可能格式沒問題，但內容不全，也會返回400。（可由開發(fā)決定）
401 Unauthorized: 由于缺乏目標資源要求的身份驗證憑證
403 Forbidden: 服務器端有能力處理該請求，但是拒絕授權訪問
404 Not Found：服務器端無法找到所請求的資源
405 Method Not Allowed: 服務器禁止了使用當前HTTP方法的請求（有能力，但是禁止）
406 Not Acceptable: 服務器端無法提供與Accept-Charset以及Accept-Language 指定的值相匹配的響應
408 Request Timeout: 服務器想要將沒有在使用的連接關閉
一些服務器會在空閑連接上發(fā)送此消息，即使是在客戶端沒有發(fā)送任何請求的情況下
500 Internal Server Error: 所請求的服務器遇到意外的情況并阻止其執(zhí)行請求
501 Not Implemented: 請求的方法不被服務器支持，因此無法被處理
-服務器必須支持的方法（即不會返回這個狀態(tài)的方法） 只有GET和HEAD
502 Bad Gateway: 作為網關或代理角色的服務器，從上游服務器（如tomcat）中接收到的響應是無效的
503 Service Unavailable：服務器尚處于可以接受請求的狀態(tài)
-通常造成這種情況的原因是由于服務器停機維護或已超載
form提交 - 常用屬性
html 里form里的button, 默認類型 type = submit
form提交，文件上傳必須使用multipart/form-data
-action: 請求的URI
-method: 請求方法（GET、POST）
-enctype: POST請求時，請求體的編碼方式
application/x-www-form-urlencoded(默認值)
用&分隔參數，用=分割鍵和值，字符用URL編碼方式進行編碼
getParameter, 只能取urlencoded的方法取值
multipart/form-data的類型，不能通過getParameter取出。需要從content-type 的boundary取出每一段的數據
Java里可以用第三方庫取出這些值，幫助解析請求體。 第三方庫 Commons-fileupload
form提交 - multipart/form-data
參考RFC_1521
請求頭
Content-Type:multipart/form-data; boundary=xxx
16.跨域_Cookie_Session
Access-Control-Allow-Origin 服務器設置，告訴瀏覽器，誰能跨域
Origin 瀏覽器發(fā)給服務器，告訴服務器源頭是什么
前后端分離：后臺工程師 JAVA
前端工程師 HTML JS CSS
頁面服務器（Nginx）
03CORS FontEdge
Index.html
后臺服務器（Tomcat）
02.Cors UserSecvlet
Idea服務器會自動開啟一個服務器
同源策略（Same-Origin Policy）（瀏覽器出于安全考慮）
瀏覽器有個同源策略 Ajax請求 異步請求的一種
-它規(guī)定了：默認情況下，Ajax請求只能發(fā)送給同源的URL
-同源是指三個相同：協(xié)議、域名（IP）、端口
-img、script、line、iframe、video、audio等標簽不受同源策略的約束
跨域資源共享和
解決Ajax跨域請求的常用方法
-CORS（Cross-Origin Resource Sharing）,跨域資源共享
CORS的實現需要客戶端和服務器同時支持
-客戶端
所有的瀏覽器都支持（IE至少是IE10版本）
-服務器
需要返回相應的響應頭（比如Access-Control-Allow-Origin）
告知瀏覽器這是一個允許跨域訪問的請求
Cookie 請求頭
Set-Cookie 響應頭
Cookie: (只針對一個瀏覽器，換了瀏覽器需重新設置Cookie)
在服務器（瀏覽器）存儲一些數據，存儲到本地磁盤（硬盤）
服務器可以返回Cookie交給客戶端去存儲
Cookie是直接存儲在瀏覽器本地的一小串數據
-使用document.cookie訪問Cookie
-修改Cookie時，只會修改其中提到的Cookie
-name = value 必須被編碼（encodeURIComponet）
-一個Cookie最大為4kb, 每個網站最多有20+個左右的Cookie(具體取決于瀏覽器)
服務器設置Cookie
Cookie通常是由Web服務器使用的響應頭Set-Cookie設置的
關于max-age
-在JavaScript
Cookie的作用域
domain和path標示定義了Cookie的作用域，即Cookie應該發(fā)送給哪些URL
domain
-標示制定了那些主機可以接受Cookie
-如果不指定，默認為當前文檔的主機（不包含子域名）；如果指定了domain, 則一般包子域名
-例如：如果設置domain=502it.com, 則Cookie也包含在子域名中（如bbs.520it.com）
Path
-標識置頂了主機下的哪些數據路徑可以接受Cookie, 子路徑也會被匹配
-例如：設置path=/docs, 則一下地址都會匹配
/docs
/docs/one/
/docs/one/img
Session
getSession內部的原理
檢查客戶端是否有發(fā)送一個叫做JSSESION的Cookie
-如果沒有
創(chuàng)建一個新的session對象，并且這個Session對象會有一個id
這個Session對象會保留在服務器的內存中
在響應的時候，會添加一個Cookie（JESSIONID=Session對象的id）給客戶端
-如果沒有
返回id為JSSESION的Session對象
Session的有效期
-session的有效期默認是30分鐘
-可以在web.xml中配置失效時間（單位是分鐘）
總結
Cookie
-數據存儲在瀏覽器客戶端
-數據有大小和數據的限制
-適合存儲一些小型、不敏感的數據
-默認情況下，關閉瀏覽器后就會銷毀
Session
-數據存儲在服務器端
-數據沒有大小和數量的限制
-可以存儲大型、敏感的數據（比如用戶數據）
-默認情況下，未使用30分鐘后就會銷毀
Cookie、Session會話跟蹤技術，請求之間是否是同一個會話。
17.代理CDN網絡安全
代理服務器（Proxy Server）
特點
-本身不生產內容
-處于中間位置轉發(fā)上下游的請求和響應
面向下游的客戶端：它是服務器
面向上游的服務器：它是客戶端
正向代理：代理的對象是客戶端
反向代理：代理的對象是服務器
正向代理 - 作用
-隱藏客戶端身份
-繞過防火墻（突破訪問限制）
-internet訪問控制
-數據過濾
-一些免費的正向代理
https://www.kuaidaili.com/free/inha/
反向代理 - 作用
-隱藏服務器身份
-安全防護
-負載均衡
抓包工具的原型
Fiddler、Charles等抓包工具的原理：在客戶端啟動了正向代理服務
需要注意
-wireshark的原理是：通過底層驅動，攔截網卡上流動的數據
代理服務器 - 相關的頭部字段
Via: 追加經過的每一臺代理服務器的主機名（或域名）
X-Forwarded-For: 追加請求方IP地址
X-Real-IP: 客戶端的真實IP地址
CDN（Content Delivery Networks 或Content distribution Network）,譯為：內部分發(fā)發(fā)網絡
利用最靠近每位用戶的服務器
更快更可靠地將音樂、圖片、視頻等資源文件（一般是靜態(tài)資源）傳遞給用戶
CDM運營商在全國，乃至全球的各大樞紐城市都建立了機房
-部署了大量擁有高存儲高寬帶的節(jié)點，構建了一個跨運營商、跨地域的專用網絡
內容所有者向CDN運營商支付費用，CDN將其內容交付給最終客戶
網絡安全問題
網絡通信中面臨的4種安全威脅
截取：竊聽通信內容
中斷：中斷網絡通信
篡改：篡改通信內容
偽造：偽造通信內容
網絡層- ARP欺騙
ARP欺騙（ARP spoofing）、又稱ARP毒化（ARP poisoning）、ARP病毒、ARP攻擊
ARP欺騙可以造成的效果
-可讓攻擊者獲取局域網上的數據包甚至可以篡改數據包
-可讓網絡上特定電腦之間無法正常通行（比如網絡執(zhí)法官這樣的軟件）
-讓送至特定IP地址的流量被錯誤送到攻擊者所取代的地方
APR欺騙 - 核心步驟舉例
-假設主機C是攻擊者，主機A、B是被攻擊者
C只要收到過A、B發(fā)送的ARP請求，就會擁有A、B的IP、MAC地址，就可以進行欺騙活動
C發(fā)送一個ARP響應給B，把響應包里的源IP設置為A的IP地址，源MAC設置為C的MAC地址
DoS、DDoS
DoS攻擊（拒絕服務器攻擊，Denial-of-Servive attack）
-使目標電腦的網絡或系統(tǒng)資源耗盡，使服務端暫時中斷或停止，導致其正常用戶無法訪問
DDoS攻擊（分布式拒絕服務器攻擊，Distributed Denial-of-Service attack）
-黑客使用網絡上兩個或兩個以上被攻陷的電腦作為“僵尸”向特定的目標發(fā)動DoS攻擊
-2018年3月，GitHub遭到迄今為止規(guī)模最大的DDoS攻擊
DoS攻擊可以分為2個大類
-帶寬消耗型：UDP洪水攻擊、ICMP洪水攻擊
-資源消耗型：SYN洪書攻擊、LAND攻擊
SYN洪水攻擊（SYN flooding attack）
-攻擊者發(fā)送一系列的SYN請求（第一次握手）到目標，然后讓目標??收不到ACK（第三次握手）而進行等待，消耗資源
攻擊方法
-跳過發(fā)送最后的SCK信息
-修改源IP地址，讓目標送SYN-ACK到偽造的IP地址，因此目標永不可能收到ACK（第三次握手）
防護
-參考 RFC_4987
傳輸層 - LAND攻擊
LAND攻擊（局域網拒絕服務攻擊，Local Area Network Denial arrack）
-通過持續(xù)發(fā)送相同源地址和目標地址的欺騙數據包，使目標試圖與自己建立連接，消耗系統(tǒng)資源直至崩潰
有些系統(tǒng)存在設計上的缺陷，允許設備接受并響應來自網絡，卻宣稱來自于設備自身的數據包，導致循環(huán)應答
防護
-大多數防火墻都能攔截類似的攻擊包，以保護系統(tǒng)
-部分操作系統(tǒng)通過發(fā)布安全補丁修復了這一漏洞
-路由器應同時配置上行與下行的篩選器，屏蔽所有源地址與目標地址相同的數據包
DoS、DDoS防御
防御方式通常為：入侵檢測、流量過濾、和多重驗證
-堵塞網絡帶寬的流量將被過濾、而正常的流量可正常通過
防火墻
-防火墻可以設置規(guī)則，例如允許或拒絕特定的通訊協(xié)議，端口或IP地址
-當攻擊從少數不正常的IP地址發(fā)出時，可以簡單的使用拒絕規(guī)則阻止一切從攻擊源IP發(fā)出的通信
-復雜攻擊難以用簡單規(guī)則來阻止，例如80端口遭受攻擊時不可能拒絕端口所有的通信，因為同時會阻止合法的流量
-防火墻可能處于網絡框架中過后的位置，路由器可能在惡意流量達到防火墻前即被攻擊影響
黑洞引導
-將所有受攻擊計算機的通信全部發(fā)送至一個“黑洞”（空接口或不存在的計算機地址）或者有足夠能力處理洪流的網絡設備商，以避免網絡收到較大的影響
流量清洗
-當流量被送到DDoS防護清洗中心時，通過采用抗DDoS軟件處理，將正常流量和惡意流量區(qū)分開
-正常的流量則回注客戶網站
應用層 - DNS劫持
DNS劫持，又稱為域名劫持
-攻擊者篡改了某個域名的解析結果，使得指向該域名的IP變成了另外一個IP
-導致對相應網址的訪問被劫持到另一個不可達的或者假冒的網址
-從而實現非法竊取用戶信息或者破壞正常網絡服務的目的
為防止DNS劫持，可以考慮更靠譜的DNS服務器，比如：114.114.114.114
-谷歌：8.8.8.8、8.8.4.4
-微軟：4.2.2.1、4.2.2.2
-百度：180.76.76.76
-阿里：223.5.5.5、223.6.6.6
HTTP劫持：對HTTP數據包進行攔截處理，比如插入JS代碼
-比如你的訪問某些網站時，在右下角多了一個莫名其妙的彈窗廣告
HTTP協(xié)議的安全問題
HTTP協(xié)議默認是采取明文傳輸的，因此會有很大的安全隱患
-常用的提高安全性的方法是：對通信內容進行加密后，在進行傳輸
18.對稱加密非對稱加密數字簽名_證書
常見的加密方式有
-不可逆
單向單列函數：MD5、SHA等
-可逆
對稱加密：DES、3DES、AES等
非對稱加密：RSA等
-其他
混合密碼系統(tǒng)
數字簽名
數字證書
iOS底層原理，iOS簽名 蘋果是如何對app進行簽名的（這個課程可以看）
常見英文
encrypt：加密
decrypt：解密
plaintext：明文
ciphertext：密文
如何防止被竊聽
單向散列函數（One-Way hash function）
單向散列函數，可以根據消息內容計算出散列值
應用：密碼加密
散列值的長度和消息長度無關，無論消息是1bit、10M、100G, 單向散列函數都會計算出固定長度的散列值 （長度20字節(jié)）
單向散列-特點
根據任意長度的消息，計算出固定長度的散列值
計算速度快，能快速計算出散列值
消息不同，散列值也不同
具備單向性
單向散列函數-稱呼
單向散列函數，也被稱為
-消息摘要函數（message digest function）
-哈希函數（hash finction）
輸出的散列值，也被稱為
-消息摘要（message digest）
-指紋（fingerprint）
MD4、MD5
-產生128bit的散列值，MD就是Message Digest的縮寫，目前已經不安全（32個十六進制字符）
SHA-1
-產生160bit的散列值，目前已經不安全
SHA-2
-SHA-256、SHA-384、SHA-512，散列值長度分別是256bit、384bit、512bit
SHA-3
-全新標準
單向散列函數-幾個網址
MD5加密
https://www.cmd5.com/hash.aspx
MD5解密
暴力破解，枚舉各種數據。但是數據源是無窮無盡的，MD5密文是有限的
其他加密
https://www.sojson.com/encrypt_des.html
https://tool.chinaz.com/tools/md5.aspx
單向散列函數 - 應用：防止數據被篡改（檢測數據是否被篡改）
鏡像站點，為了分散通信負荷而從鏡像站點下載軟件
官網站點，對比鏡像站點的散列值，為了確認完整性，從原始網址獲取到散列
應用：密碼加密
18.對稱加密非對稱加密數字簽名_證書
如何加密解密？
對稱加密（Symmetric Cryptography）:加密用的密鑰 = 解密用的密鑰
常用的：
AES（Advanced Encryption Standard）
-取代DES成為新標準的一種對稱加密算法，又稱為Rijndeal加密法
-AES的密鑰長度有128、192、256bit三種（密鑰越長破解難度越大）
-目前AES，已經逐步取代DES，3DES，成為首選的對稱加密算法
它經過了全世界密碼學家所進行的高品質驗證工作
DES（Data Encryption Standard）
-DES 是一種將64bit 明文加密成64bit密文的加密算法，密鑰長度是56bit
-規(guī)格上來說，密鑰長度是64bit, 但每隔7bit會設置一個用于錯誤檢查的bit, 因此密鑰長度實質上是56bit
-由于DES每次只能加密64bit的數據，遇到比較大的數據，需要對DES加密進行迭代（反復）
-目前已經可以在短時間內被破譯，所以不建議使用
3DES（Triple Data Encryption Algorithm）
3DES, 將DES重復3次所得到的一種密碼算法，也叫做3DES
-三重DES并不是進行3次DES加密（加密->加密->加密）
-而是加密（Encryption）-> 解密（Decryption）-> 加密（Encryption）的過程
-目前還被一些銀行等機構使用，但處理速度不高，安全性逐漸暴露出問題
-3個密鑰都是不相同的，也叫DED-EDE3
-如果所有的密鑰相同，則結果與普通DES是等價的 （無效用法）
-如果密鑰1，密鑰3相同，密鑰2不同，稱為DES-EDE2
——————————————————————————————————————————————————————————
非對稱加密（公鑰密碼）：（Asymmetric Cryptography）
-在非對稱jimmy，密鑰分為加密密鑰、解密密鑰2中，它們并不是同一個密鑰
-加密密鑰一般是公開的，因此該密鑰稱為公鑰（Public key）
因此，非對稱加密也被稱為公鑰密碼算法（Public-key Cryptography）
-解密密鑰：有消息接受者自己保管的，不能公開，因此也稱為私鑰（private key）
公鑰、私鑰
公鑰和私鑰是一一對應的，不能單獨生成
-一對公鑰和私鑰統(tǒng)稱為密鑰對（Key pair）
由公鑰加密的密文，必須使用與該公鑰對應的私鑰才能解密
由私鑰加密的密文，必須使用與該私鑰對應的公鑰才能解密
RSA
目前使用最廣泛的非對稱加密算法是RSA
RSA的名字，由他的3位開發(fā)者，即Ron Rivest、 Adi Shamir、Leonard Adleman的姓氏首字母組成
——————————————————————————————————————————————————————————
密鑰配送問題
-在使用對稱加密時，一定會遇到密鑰配送問題
-如果Alice將使用對稱加密過的信息發(fā)給了Bob
只有將密鑰發(fā)送給Bob,Bob才能完成解密
在發(fā)送過程中：可能會被竊聽，對方也能完成解密
如何解決密鑰配送問題
有以下幾種解決密鑰配送的方法
-事先共享密鑰（比如私下共享）
-密鑰分配中心（Key Distribution Center, 簡稱KDC）
-Diffie-Hellman密鑰交換
解決密鑰配送問題
由消息的接收者，生成一對公鑰、私鑰
將公鑰發(fā)給消息的發(fā)送者
消息的發(fā)送者使用公鑰加密消息
非對稱加密的加密解密速度比較對稱加密要慢
-非對稱加密：復雜->安全->加密解密速度慢
-對稱加密：簡單->不安全->加密解密速度快
混合密碼系統(tǒng)（Hybird Cryptosystem）
對稱加密的缺點
-不能很好的解決密鑰配送問題（密鑰會被竊聽）
非對稱加密的缺點
-加密解密速度比較慢
混合密鑰系統(tǒng)：是將對稱加密和非對稱加密的優(yōu)勢相結合的方法
-解決了非對稱加密速度慢的問題
-并通過非對稱加密解決了對稱加密的密鑰配送問題
網絡上密碼通信所用的SSL/TLS都運用了混合密碼系統(tǒng)
混合密碼
會話密鑰（Session key）
-為本次通信隨機生成的臨時密鑰（例如隨機數）
-作為對稱加密的密鑰，用于加密消息，提高速度
加密步驟（發(fā)送消息）
1.首先，消息發(fā)送者要擁有消息接受接收的公鑰
2.生成會話密鑰（隨機數），作為對稱加密的密鑰，加密消息（生成密文A）
3.用消息接收者的公鑰，加密會話密鑰（2的隨機數）（生成密文B）
4.將前兩步生成的加密結果，AB一并發(fā)送給消息接收者
發(fā)送出去的內容包括
-用會話密鑰加密的消息（加密方法：對稱加密）
-用公鑰加密的會話密鑰（加密方法：非對稱加密）
A —> B 的msg, 一定用對稱加密，因為msg大小不確定
混合密碼 — 解密
解密步驟（收到消息）
1.消息接收者用自己的密鑰解密（密文B）出會話密鑰
2.再用第一步解密出來的會話密鑰，解密消息
數字簽名
服務器如何確認消息的真實性？
在數字簽名技術中，有一下2種行為
-生成簽名：由消息的發(fā)送者完成，通過“簽名密鑰”生成
-驗證簽名：由消息的接受者完成，通過“驗證密鑰”驗證
過程改進
1.消息進行MD5，拿到固定長度
2.利用私鑰對散列值進行簽名
Q：如何能保證這個簽名是消息發(fā)送者之間簽的？
A：用消息發(fā)送者的私鑰進行簽名
Q: 如果有人篡改了消息內容或簽名內容，會是什么結果？
A：簽名驗證失敗，證明內容被篡改了
Q：數字簽名不能保證機密性？
A：數字簽名的作用不是為了保證機密性，僅僅是為了能夠識別內容有沒有被篡改
數字簽名的作用：
1.確認消息的完整性
2.識別消息是否被篡改
3.防止消息發(fā)送人否認
非對稱加密 - 公鑰、私鑰再總結
在非對稱加密中，任何人都可以使用公鑰進行加密
在數字簽名中，任何人都可以用公鑰驗證簽名
數字簽名，就是將非對稱加密反過來使用
既然是加密，那肯定是不希望別人知道我的消息，所以只有我能解密。
-公鑰負責加密，私鑰負責解密
既然是簽名，那肯定是不希望有人冒充我發(fā)送消息，所以只有我能簽名
-私鑰負責簽名，公鑰負責驗簽
公鑰的合法性
如果遭遇了中間人攻擊，那么
-公鑰有可能是偽造的
如何驗證公鑰的合法性
-證書
是消息發(fā)送者能拿到真正的公鑰，利用權威機構認證過的公鑰。
認證權威機構，再拿公鑰
證書（Certificate）
說到證書
-首先聯(lián)想到的是駕駛證、畢業(yè)證、英語四六級等等，都是由權威機構認證的
密碼學中的證書，全城是公鑰證書（Public-key Certificate, PKC）,跟駕駛證類似
-里面有姓名、郵箱等個人信息，以及此人的公鑰
-并由認證機構（Certificate Authority, CA）,施加數字簽名
CA就是能夠認定“公鑰屬于此人”，并能夠生成數字簽名的個人或組織
-有國際性組織、政府設立的組織
-有通過提供認證服務來盈利的企業(yè)
-個人也可以成立認證機構
