前言

計算機網(wǎng)絡(luò)是計算機專業(yè)很重要的一門課竹捉，課程中詳細闡述了兩臺計算機之間是如何進行通信罚屋、如何保證通信的可靠性廊镜、如何保證通信的高效性等等內(nèi)容，在日常coding中可能比較少關(guān)注到這方面焰情，但是在真正遇到網(wǎng)絡(luò)方面的問題無法解決時，了解計算機網(wǎng)絡(luò)的原理卻是十分必要的剥懒。

OSI七層網(wǎng)絡(luò)模型

• OSI七層網(wǎng)絡(luò)模型縮略圖

  OSI七層模型

• 自底向上理解七層網(wǎng)絡(luò)模型

  工程學科是不斷迭代的過程内舟，因此七層協(xié)議大概是這么進化來的。

  • 物理層

    物理層解決了兩臺機器之間相互通信的問題蕊肥，首先機器A發(fā)送了一些比特流谒获，機器B需要收到這些比特流蛤肌，這就是物理層所做的事情。物理層主要定義了網(wǎng)絡(luò)設(shè)備的標準批狱，例如接口的類型裸准、機器的類型、網(wǎng)絡(luò)的類型等赔硫。其傳輸?shù)臄?shù)據(jù)主要是bit流炒俱，也就是010101....這類數(shù)據(jù)，以電流強弱定義爪膊，也就是D/A or A/D轉(zhuǎn)換权悟。物理層的分組稱為bit。

  • 數(shù)據(jù)鏈路層

    在傳輸bit流的過程中推盛，會產(chǎn)生錯傳峦阁、數(shù)據(jù)傳輸不完整的情況，數(shù)據(jù)鏈路層就應運而生耘成。數(shù)據(jù)鏈路層主要定義數(shù)據(jù)格式化傳輸榔昔、以及如何控制對物理介質(zhì)的訪問，通常還有錯誤控制和糾正瘪菌，處理錯誤數(shù)據(jù)撒会。這一層將分組稱為幀。

  • 網(wǎng)絡(luò)層

    在數(shù)據(jù)傳輸?shù)倪^程中师妙，需要有數(shù)據(jù)發(fā)送方和數(shù)據(jù)接收方诵肛，而且在網(wǎng)絡(luò)越來越復雜的變化中，如何在多個節(jié)點中找到最佳路徑精準地找到接收方默穴，這就是網(wǎng)絡(luò)層需要做的事怔檩。網(wǎng)絡(luò)層會將網(wǎng)絡(luò)地址翻譯為對應的物理地址，然后通過計算壁顶，得出從節(jié)點A到節(jié)點B的最佳路徑珠洗，本層的協(xié)議是IP協(xié)議，在本層中將分組稱為數(shù)據(jù)報若专。

  • 傳輸層

    在網(wǎng)絡(luò)層傳輸?shù)倪^程中许蓖，會中斷好多次，所以需要把發(fā)送的信息切割為一個一個的Segment调衰，分段傳輸膊爪，那么其中一段發(fā)送失敗了或出現(xiàn)錯誤了，要怎么辦嚎莉，是否需要重傳米酬，這就是傳輸層需要干的事。傳輸層保證了傳輸?shù)馁|(zhì)量趋箩，這層也被稱為OSI七層模型中最重要的一層赃额，本層需要關(guān)注的協(xié)議為TCP/UDP協(xié)議加派。另外傳輸層會將數(shù)據(jù)報進行進一步切割，例如：以太坊無法接收大于1500Byte的數(shù)據(jù)報跳芳，于是傳輸層就將報文分割為多個報文段芍锦，并按順序發(fā)送，并且傳輸層是負責端到端的傳輸飞盆。

  • 會話層

    會話層的作用就是建立和管理應用程序之間的通信娄琉，無需用戶過多地參與到TCP/IP協(xié)議中。

  • 表示層

    表示層可以幫助我們翻譯在不同類型網(wǎng)絡(luò)上的數(shù)據(jù)吓歇，例如加密解密孽水、轉(zhuǎn)換翻譯、壓縮解壓縮等城看。

  • 應用層

    應用層規(guī)定發(fā)送方和接收方必須使用固定長度的消息頭女气，并且封裝了各種的報文信息，旨在使用戶更方便地應用網(wǎng)絡(luò)中接收到的數(shù)據(jù)析命，該層需要關(guān)注的協(xié)議為HTTP協(xié)議主卫，該層的分組稱為報文。

  網(wǎng)絡(luò)數(shù)據(jù)處理流程為鹃愤，發(fā)送方先自上而下封裝，接收方自下而上解封數(shù)據(jù)完域。而事實上OSI并沒有真正實現(xiàn)網(wǎng)絡(luò)软吐，而TCP/IP五層模型實際上是對OSI參考模型的實現(xiàn)。

TCP/IP協(xié)議族

• 傳輸控制協(xié)議（Transmission Control Protocol）簡介

  • 面向連接的吟税、可靠的凹耙、基于字節(jié)流的傳輸層通信協(xié)議
  • 將應用層的數(shù)據(jù)流分割成報文段并發(fā)送給目標節(jié)點的TCP層
  • 報文段都有序號，對方收到則發(fā)送ACK確認肠仪，未收到則重傳

• TCP的報文頭

TCP報文頭

- 源端口：發(fā)送方的端口號
- 目的端口：接收方的端口號
- 序號：TCP報文段的序號
- 確認序號：接收方接收到了序號為x的報文段肖抱，期待收到序號為x+1為起始的報文段。
- 數(shù)據(jù)偏移：報文段在整個報文中偏移的字節(jié)量
- 保留域：備用區(qū)
- 標志位：URG(緊急信息)异旧、ACK(確認標志位)意述、PSH(為1則收到信息收立即交給進程，無需再隊列中等待)吮蛹、RST(重置標連接)荤崇、SYN(請求連接)、FIN(結(jié)束連接)
- 檢驗和：檢驗數(shù)據(jù)是否正確

• TCP的三次握手

  三次握手

  TCP是面向連接的協(xié)議潮针，在進行三次握手的過程后术荤，TCP將建立一條全雙工的連接。為什么要進行三次握手呢每篷？其一瓣戚，主要是為了確認客戶機和服務器同時具備發(fā)送和接收的能力端圈，第一次握手，服務器確認了客戶機的發(fā)送能力子库，第二次握手枫笛，客戶機確認了服務器的接收能力和發(fā)送能力，第三次握手刚照，服務器確認了客戶機的接收能力刑巧。其二，是需要初始化seq的序號无畔，以免在正式傳輸中出現(xiàn)亂序啊楚。
  三次握手過程如下：
  1.客戶機首先向服務器發(fā)送連接請求，此時SYN標志位為1浑彰，且seq=x恭理，x為一個大于等于1的正整數(shù)，此時服務器為Listen狀態(tài)郭变，客戶端處于SYN-SENT狀態(tài)颜价。
  2.服務器收到了來自客戶機的請求，返回應答诉濒，此時SYN標志位為1周伦，ACK標志位為1，ack=x+1（代表期望收到起始為seq=x+1的報文段）未荒，seq=y专挪，此時服務器處于SYN-RCVD狀態(tài)，客戶端處于ESTABLISHED狀態(tài)片排。
  3.客戶機收到了服務器返回的應答報文寨腔，于是發(fā)送自己的應答報文，響應服務器的應答率寡，此時ACK標志位為1迫卢，seq為x+1（響應ack需求）该溯，ack=y+1（表示期望從服務器獲取y+1為起始的報文段）丧蘸，此時服務器處于ESTABLISHED狀態(tài)。完成三次握手震放。

• TCP的四次揮手

  四次揮手

  四次揮手由客戶端或服務端任意一端close比默。
  過程（假設(shè)由客戶端主動關(guān)閉）
  1.客戶端發(fā)送關(guān)閉連接請求幻捏，此時FIN標志位為1，seq=u命咐。
  2.服務端返回應答報文篡九，此時ACK標志位為1，seq=v醋奠，ack=u+1（表示期望得到u+1為起始的報文段）榛臼，等待一段時間伊佃，并且傳送剩余數(shù)據(jù)（如果有的話）。
  3.服務端發(fā)送關(guān)閉連接請求沛善，此時FIN標志位為1航揉，ACK標志位為1，seq=w金刁，ack=u+1帅涂。
  4.客戶端返回應答請求，此時ACK標志位為1尤蛮，seq=u+1媳友，ack=w+1。發(fā)送過后服務端立即關(guān)閉連接产捞，客戶端等待一段時間（2MSL醇锚，一分鐘左右），確定后續(xù)無數(shù)據(jù)傳送坯临，則自行關(guān)閉連接焊唬。

  為什么需要有2MSL的等待時間？
  1.確保對方收到自己的ACK看靠，如果對方未收到ACK則會重發(fā)FIN請求赶促，一來一回正好為2ML。
  2.避免新舊連接混淆衷笋。

  為什么需要四次揮手芳杏？
  因為確保服務器端和客戶端都有FIN和ACK。

• SYN Flood洪泛攻擊

  其原理是：例用三次握手的規(guī)則辟宗，在客戶機向服務器發(fā)送請求后，在服務器發(fā)送SYN-ACK后下線吝秕，服務器則無法收到ACK確認泊脐，服務器段則會不斷重試，重試間隔為1s,2s,4s,8s,16s,32s烁峭，在linux默認狀況下會等待63s容客，如果有大量的連接重復此過程，則會造成服務器連接隊列耗盡约郁，這就是洪泛攻擊的原理缩挑。
  防護措施：linux下設(shè)置了TCP_SYN_Cookies參數(shù)，若為正常連接鬓梅，客戶機發(fā)回SYN Cookie供置，如果為異常連接，就不發(fā)回绽快，但也不會影響到連接隊列芥丧。
  建立連接后客戶機突然出現(xiàn)故障：服務器默認“苯衾活機制”，會在一定時間內(nèi)發(fā)送請求续担，若幾次請求無應答擅耽，則將該客戶機標識為不可達客戶機。

• TCP與UDP區(qū)別

  首先先看UDP報文頭：

  
  
  UDP報文頭

  UDP報文頭由源端口號物遇、目的端口號乖仇、報文段長度、檢驗和組成询兴。長度為8個字節(jié)乃沙。而TCP為20個字節(jié)。

  • UDP的特點

    1.面向非連接蕉朵，傳輸速度快崔涂。
    2.支持同時向多個客戶端傳輸信息。
    3.報文段報文頭只有8個字節(jié)始衅，額外開銷小冷蚂。
    4.吞吐量只受限于數(shù)據(jù)生成速率、傳輸速率以及機器性能汛闸。
    5.盡最大努力交付蝙茶，不保證可靠交付，不需要維持復雜的連接狀態(tài)表诸老。
    6.面向報文隆夯，不對應用程序提交的信息進行拆分或合并。

  結(jié)論：
  1.TCP面向連接别伏，UDP面向無連接
  2.TCP可靠蹄衷，UDP不可靠
  3.TCP有序，UDP可能無序
  4.TCP速度慢厘肮，UDP速度快
  5.TCP重量級愧口，UDP輕量級

• TCP中的滑動窗口

  滑動窗口是避免發(fā)送方發(fā)送過量數(shù)據(jù)導致接收方緩存無法接收以至于數(shù)據(jù)丟失的問題，主要在報文頭的window字段中类茂，接收方會告訴發(fā)送方自己的緩存還可以接收多少數(shù)據(jù)耍属，而發(fā)送方可以根據(jù)這一信息，調(diào)整自己將要發(fā)送的數(shù)據(jù)巩检。

  
  
  滑動窗口

  如上圖所示厚骗，發(fā)送方窗口分為三段：
  1.LastByteAcked：最后被確認到的數(shù)據(jù)位置
  2.LastByteSent：已發(fā)送的數(shù)據(jù)的最后一個字節(jié)位置
  3.LastByteWritten：程序向滑動窗口寫入的數(shù)據(jù)位置
  接收方窗口分為三段：
  1.LastByteRead：最后被應用程序讀取到的數(shù)據(jù)（已經(jīng)發(fā)送ACK）位置
  2.NextByteExpected：收到的但還未發(fā)送ACK的數(shù)據(jù)位置
  3.LastByteRcvd：已收到的最后一個字節(jié)的位置。
  計算方式
  接收方還可處理量：AdvertisedWindow = MaxRcvBuffer（最大緩存） - (LastByteRcvd-LastByteRead)
  發(fā)送方可發(fā)送量：EffectiveWindow = AdvertiseWindow-(LastByteSent - LastByteAcked)
  解讀：
  接收方可處理量為 = 最大緩存 - 已收到的報文段（已收到的最后一個字節(jié)的位置-程序讀取到的數(shù)據(jù)的位置）
  發(fā)送方可發(fā)送量 = 接收方可處理量 - 待確認量（發(fā)送方最后發(fā)送的字節(jié)位置 - 發(fā)送了并且已獲取確認的位置）

  發(fā)送方滑動窗口的四類數(shù)據(jù)：
  

  TCP滑動窗口四類

  1.已發(fā)送并且被確認的數(shù)據(jù)
  2.已發(fā)送但未得到確認的數(shù)據(jù)
  3.未發(fā)送但接收方同意發(fā)送的數(shù)據(jù)
  4.未發(fā)送且接收方拒絕的數(shù)據(jù)
  接收方滑動窗口三類數(shù)據(jù)
  

  TCP滑動窗口三類

  1.接收且已確認的數(shù)據(jù)
  2.未接收但可以接收的數(shù)據(jù)
  3.未接收且無法接收的數(shù)據(jù)
  當接收方滑動窗口不足時兢哭，發(fā)送方是不會移動自己的滑動窗口的领舰，只有當發(fā)送方的滑動窗口之前的所有數(shù)據(jù)都被確認，發(fā)送方的滑動窗口才會向后移動，這也是TCP保證數(shù)據(jù)完整性的重要手段提揍。

HTTP協(xié)議

• HTTP簡介

  HTTP：超文本傳輸協(xié)議
  1.支持客戶/服務器模式
  2.簡單快速
  3.靈活
  4.無連接：限制每次連接只處理一個請求啤月，但從HTTP1.1起，默認使用長連接劳跃。
  5.無狀態(tài)
  HTTP版本現(xiàn)在有常用的1.0和1.1谎仲，還有2.0，1.1在1.0的基礎(chǔ)上做了keep-alive長連接技術(shù)刨仑，而2.0雖然在各種思想上都顯得更加合理郑诺，但是1.1基本能滿足日常需求且更換2.0消耗大，所以2.0目前并沒有推廣開杉武。

• HTTP請求報文
  

  http請求報文
  
  請求行：

  請求方式 url 協(xié)議版本
  頭部字段名:值
  ......
  頭部字段名:值
  請求正文

  例如：

  POST /user HTTP/1.1 //請求行
  Host: www.baidu.com
  Content-Type: application/x-www-form-urlencoded
  Connection: Keep-Alive
  User-agent: Mozilla/5.0. //以上是首部行
  （此處必須有一空行） //空行分割header和請求內(nèi)容
  name=world 請求體

• HTTP報文頭

  HTTP報文頭

• 請求/響應的步驟
  1.客戶端連接到Web服務器
  2.發(fā)送HTTP請求
  3.服務器接受請求并返回HTTP響應
  4.釋放TCP連接（如果是keep-alive則保持一段時間）
  5.客戶端解析HTML內(nèi)容

• 關(guān)于HTTP的面試題

  1.在瀏覽器地址欄鍵入URL辙诞，按下回車后經(jīng)歷的流程。
  答：首先要進行DNS解析轻抱，將訪問的域名解析為IP地址飞涂，解析是由近到遠的，首先在瀏覽器緩存中尋找是否有對應的IP祈搜，如果沒有則進入系統(tǒng)緩存较店，如果沒有則按照路由器緩存->IPS服務器緩存->根域名緩存->頂級域名服務器緩存，這樣一路查找容燕，直到找到了則停止查找梁呈，直接返回。然后進行TCP連接蘸秘，默認端口80官卡，進行三次握手（可以簡單描述三次握手的流程），建立連接后發(fā)送HTTP請求醋虏，服務器處理請求并返回HTTP報文寻咒，瀏覽器解析并渲染頁面，最后連接結(jié)束颈嚼。

  2.常見的HTTP狀態(tài)碼仔涩。
  答：先分類。
  1xx提示信息--表示請求已接受粘舟，繼續(xù)處理
  2xx表示成功連接
  3xx重定向--要完成請求必須進行更進一步操作
  4xx表示瀏覽器（客戶端）出現(xiàn)錯誤
  5xx表示服務器端出現(xiàn)錯誤
  常見的HTTP狀態(tài)碼：
  200 ok，成功連接
  400 bad request(客戶端請求語法錯誤佩研，服務器無法理解)
  401:未經(jīng)授權(quán)
  403:拒絕服務
  404:Not Found
  500內(nèi)部服務器錯誤
  503：當前不能處理柑肴，一段時間后可能

  3.GET和POST請求的區(qū)別。
  答：1.HTTP報文層面：GET請求信息放在URL后（?XXX=XXX&XX=XXX）旬薯，POST放在報文體晰骑，安全一些（但其實沒什么區(qū)別，抓包可以直接抓到報文）
  2.數(shù)據(jù)庫層面：GET符合冪等性（對數(shù)據(jù)庫一次或多次操作，結(jié)果是一致的）和安全性（對數(shù)據(jù)庫一次或多次操作硕舆，沒有改變數(shù)據(jù)庫中的數(shù)據(jù)）秽荞，GET是做查詢操作的，不會改變數(shù)據(jù)庫中的數(shù)據(jù)抚官。
  3.POST插入扬跋，每次請求都有可能不一樣。
  其他層面凌节，GET可以被CDN緩存钦听，被存儲，在服務量巨大的環(huán)境下倍奢，又有大部分的數(shù)據(jù)是只讀的朴上，所以我們并不想讓服務器完全處理，就可以使用GET請求卒煞，但POST不行,POST必須交由服務器處理痪宰。

  4.Cookie和Session的區(qū)別
  Cookie是客戶端解決方案，由服務器發(fā)給客戶端的特殊信息畔裕，以文本的形式存放在客戶端衣撬。
  Cookie使用過程：
  1.用戶向服務器發(fā)送個人識別信息，服務器也向客戶端發(fā)送Cookie文件柴钻。
  2.客戶端再次發(fā)送請求時淮韭，也會把cookie發(fā)送回去。
  3.服務端會獲取cookie從而生成與客戶端相對應的內(nèi)容贴届。
  Session 服務端解決方案,Session是在服務器上保存的信息靠粪。服務器解析客戶端請求并操作SessionId，按需保存狀態(tài)信息毫蚓。如果客戶端包含SessionId則直接使用占键，如果不包含則創(chuàng)建一個。
  Session實現(xiàn)方式：
  1.使用Cookie實現(xiàn)
  客戶端向服務端發(fā)送請求元潘，服務端返回響應報文并SetCookie畔乙，Cookie中含有JSESSIONID-XXXXX，客戶端之后的每次請求都會攜帶這個Cookie翩概，服務端根據(jù)這個Cookie中的Session提供響應的內(nèi)容牲距。
  2.使用URL回寫實現(xiàn)
  使用URL回寫即在URL地址中攜帶JSESSIONID這個參數(shù)。
  Tomcat同時支持Cookie和URL回寫钥庇，默認使用Cookie牍鞠，當瀏覽器拒絕Cookie時，則使用URL回寫的方式實現(xiàn)Session
  區(qū)別：
  Cookie是以文件的形式存儲在客戶端评姨，而Session是在服務器端進行處理的难述，Session相對Cookie來說比較安全，因為Cookie存儲在客戶端，容易被修改胁后，而Session存在于服務器端店读，無法被修改，但Session會占用服務器資源攀芯，影響服務器性能屯断，如果考慮服務器性能優(yōu)先，則可以考慮多使用Cookie敲才。

• HTTP和HTTPS區(qū)別

  HTTPS：超文本傳輸安全協(xié)議
  HTTP:HTTP+TCP+IP
  HTTPS:HTTP+(SSL OR TLS)+TCP+IP
  要說HTTP和HTTPS的區(qū)別首先要提到SSL和加密方式裹纳。

• SSL:Security-Sockets-Layer,安全套接層

  SSL是為網(wǎng)絡(luò)通信提高安全及數(shù)據(jù)完整性的一種安全協(xié)議，是操作系統(tǒng)對外的API紧武，SSL3.0后更名為TLS剃氧，采用身份驗證和數(shù)據(jù)加密保證網(wǎng)絡(luò)通信安全和數(shù)據(jù)的完整性。

• 加密的幾種形式

  • 1.對稱加密
    對稱加密是一種可以進行解密的加密方式阻星，其特點就是朋鞍，將一個數(shù)據(jù)按照一定過程加密，那么按照這個過程的反過程一定可以將這個數(shù)據(jù)進行解密妥箕。其特點是效率高滥酥，但安全性低。
  • 2.非對稱加密
    非對稱加密的特點是加密使用的密鑰和解密使用的密鑰是不相同的畦幢，即坎吻，將一條數(shù)據(jù)按照一定的過程進行加密，按照這個過程的反過程并不能逆推回加密數(shù)據(jù)的源數(shù)據(jù)宇葱，而只能通過另一種特定的方式進行解密瘦真，這就是非對稱加密。非對稱加密的安全性高黍瞧，但效率不如對稱加密诸尽。
  • 3.Hash加密
    Hash加密，將任意長度的信息轉(zhuǎn)換為固定長度的值印颤，其加密的數(shù)據(jù)是不可逆的您机，一般日常所用的加密方式是MD5方式。
  • 4.數(shù)字簽名
    在信息后加一段Hash值年局，證明某個消息或文件時某人發(fā)出的际看，且可以證明信息沒有被修改。

• HTTPS使用的加密方式

  HTTPS使用證書+各種加密方式共同加密
  加密的三次握手過程：
  1.瀏覽器將支持的加密算法信息發(fā)送給服務器
  2.服務器選擇一套瀏覽器支持的加密方式矢否，以證書的形式回發(fā)給瀏覽器仿村。包含CA機構(gòu)，公鑰兴喂，有效期，所有者等。
  3.瀏覽器驗證證書的合法性衣迷，并結(jié)合證書公鑰畏鼓，加密信息發(fā)送給服務器。
  4.服務器使用私鑰解密壶谒，驗證hash云矫，加密響應消息回發(fā)瀏覽器
  5.瀏覽器對響應消息進行解密，并對消息進行驗證汗菜，之后進行密文交互數(shù)據(jù)让禀。

• 區(qū)別

  HTTPS需要到CA申請證書，而HTTP不需要陨界。
  HTTPS的證書是需要收費的巡揍，HTTP不收費。
  HTTPS默認端口為443菌瘪，HTTP默認端口為80腮敌。
  HTTPS為有狀態(tài)協(xié)議，HTTP為無狀態(tài)協(xié)議俏扩。

雖說HTTPS是安全協(xié)議糜工，但是HTTPS也未必安全，在瀏覽器默認填充http:// 的情況下訪問https的網(wǎng)站录淡，請求需要進行跳轉(zhuǎn)捌木，這個過程中就有被劫持的風險。但可以使用HSTS優(yōu)化（自行了解）嫉戚。

Socket

• Socket概念

  Socket是對TCP/IP協(xié)議的抽象刨裆，是操作系統(tǒng)對外開放的接口，如果一定要按層次來理解Socket的話彼水，Socket位于傳輸層之上崔拥，應用層之下》锔玻可以把它理解為一扇門链瓦，各種請求可以通過這扇門和和系統(tǒng)進行通信。

• Socket 通信流程

  Socket流程

• Socket 通信原理

  我們知道盯桦，在進程間通信我們可以通過管道慈俯、共享內(nèi)存等等等等方式，但是無論使用哪一種方式拥峦，通信的本質(zhì)都是需要被通信的對象有一個可以唯一標識的標識符贴膘。在進程間通信時，進程的標識符為PID略号，而在網(wǎng)絡(luò)通信中刑峡，我們首先要使用IP標識主機洋闽，TCP+端口號標識進程。而端口號就相當于門牌號突梦，Socket可以監(jiān)聽某個端口來使該進程與某個請求進行交互诫舅。而Socket是基于Unix而生的，Unix奉行的宗旨就是宫患，一切皆文件刊懈，所以Socket的本質(zhì)就是在讀寫特定的Socket文件，以達到通信的目的娃闲。

結(jié)語

通過上文的敘述虚汛，可以大概了解OSI七層網(wǎng)絡(luò)模型的“各司其職”、了解TCP/IP協(xié)議族皇帮、還有三次握手四次揮手的整個過程卷哩、了解洪泛攻擊的原理、TCP/UDP的區(qū)別以及TCP中擁塞控制之滑動窗口玲献，還了解了HTTP協(xié)議以及HTTP安全協(xié)議——HTTPS殉疼，還稍微談到了點Socket。
計算機網(wǎng)絡(luò)是一門大的學科捌年，上面所說的也不過百分之二三瓢娜，寥寥而已。但是基本可以滿足日常開發(fā)所需礼预。

本文圖片來自網(wǎng)絡(luò)眠砾，侵刪。

歡迎大家訪問我的個人博客：Object's Blog