值得關(guān)注的博客：
GCD：http://www.cnblogs.com/snailHL/p/3906112.html信號量的理解
HTTP1.1閱讀筆記：
狀態(tài)碼：以“if-”打頭的都是客戶端發(fā)出的抑月。eg“If-Modified-Since”
HTTP為何需要3次握手建立聯(lián)系，四次掛斷？
“三次握手”的目的是“為了防止已失效的連接請求報文段突然又傳送到了服務(wù)端薄辅，因而產(chǎn)生錯誤拗窃。client發(fā)出的第一個連接請求報文段并沒有丟失踩萎，而是在某個網(wǎng)絡(luò)結(jié)點長時間的滯留了棋蚌，以致延誤到連接釋放以后的某個時間才到達server岛抄。本來這是一個早已失效的報文段纫普。但server收到此失效的連接請求報文段后阅悍，就誤認為是client再次發(fā)出的一個新的連接請求。于是就向client發(fā)出確認報文段昨稼，同意建立連接节视。假設(shè)不采用“三次握手”，那么只要server發(fā)出確認假栓，新的連接就建立了寻行。由于現(xiàn)在client并沒有發(fā)出建立連接的請求，因此不會理睬server的確認匾荆，也不會向server發(fā)送數(shù)據(jù)拌蜘。但server卻以為新的運輸連接已經(jīng)建立，并一直等待client發(fā)來數(shù)據(jù)牙丽。這樣简卧，server的很多資源就白白浪費掉了。采用“三次握手”的辦法可以防止上述現(xiàn)象發(fā)生烤芦。例如剛才那種情況举娩，client不會向server的確認發(fā)出確認。server由于收不到確認构罗，就知道client并沒有要求建立連接铜涉。”
這是由于TCP的半關(guān)閉造成的,因為TCP連接是全雙工的（即數(shù)據(jù)可在兩個方向上同時傳遞)所以進行關(guān)閉時每個方向上都要單獨進行關(guān)閉,這個單方向的關(guān)閉就叫半關(guān)閉.關(guān)閉的方法是一方完成它的數(shù)據(jù)傳輸后,就發(fā)送一個FIN來向另一方通告將要終止這個方向的連接.當(dāng)一端收到一個FIN,它必須通知應(yīng)用層TCP連接已終止了這個方向的數(shù)據(jù)傳送,發(fā)送FIN通常是應(yīng)用層進行關(guān)閉的結(jié)果.
Head of Line Block：隊列的首個packet由于它的目的端口正忙而被延遲轉(zhuǎn)發(fā)遂唧，導(dǎo)致后面的packets被blocked芙代。
pipelining（管道化）：后面的請求不用等前面的請求response返回之后才發(fā)出head of line blocking并沒有完全得到解決，server的response還是要求依次返回
HTTP2.0：
（1）http1.1的問題：
a盖彭，只能客戶端請求纹烹，服務(wù)器返回。服務(wù)器沒有辦法主動向客戶端發(fā)送消息召边。
b, 只能一個請求铺呵，一個返回，即使打開http1.1的管道化掌实，也無法解決該問題陪蜻，因為返回數(shù)據(jù)也是按照先后順序的邦马，如果前面的是耗時非常長的操作贱鼻，后面的也無法返回宴卖。
c, 報文頭無法壓縮，導(dǎo)致傳輸?shù)臄?shù)據(jù)量大邻悬。
MIME（也稱content_type）：
在HTTP中症昏，MIME類型被定義在Content-Type header中。
最早的HTTP協(xié)議中父丰，并沒有附加的數(shù)據(jù)類型信息肝谭，所有傳送的數(shù)據(jù)都被客戶程序解釋為超文本標(biāo)記語言HTML 文檔，而為了支持多媒體數(shù)據(jù)類型蛾扇，HTTP協(xié)議中就使用了附加在文檔之前的MIME數(shù)據(jù)類型信息來標(biāo)識數(shù)據(jù)類型攘烛。（baidu之）
如果是某個客戶端自己定義的格式，一般只能以 application/x- 開頭镀首。
https特點：
cer可以認為是公鑰坟漱。
P12備份文件 = cer文件 + 私鑰；
自簽名證書：
該協(xié)議包括兩部分：（1）SSL記錄協(xié)議（SSL Record Protocol）：它建立在可靠的傳輸協(xié)議（如TCP）之上更哄，為高層協(xié)議提供數(shù)據(jù)封裝芋齿、壓縮、加密等基本功能的支持成翩。
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? （2）SSL握手協(xié)議（SSL Handshake Protocol）：它建立在SSL記錄協(xié)議之上觅捆，用于在實際的數(shù)據(jù)傳輸開始前，通訊雙方進行身份認證麻敌、協(xié)商加密算法栅炒、交換加密密鑰等。使用443端口庸论。服務(wù)器和客戶端都有CA頒發(fā)的配對的證書职辅，服務(wù)器上有的是私鑰，客戶端上是公鑰聂示。https握手時候使用的是RSA（非對稱加密）域携，之后協(xié)商出一個對稱密碼，自此之后使用這個對稱密碼交流數(shù)據(jù)鱼喉。只要服務(wù)器的公鑰足夠長（比如2048位）秀鞭，那么Premaster secret（第三個隨機數(shù)）可以保證不被破解。
在http協(xié)議和tcp協(xié)議之間加一層SSL扛禽，達到保密的目的锋边。
客戶端和服務(wù)器都必須受信一個第三方的認證機構(gòu)（CA）
SSL層：SSL靠證書確認服務(wù)器的身份，并對傳輸?shù)男畔⒓用堋?/p>
1编曼，SSL記錄協(xié)議豆巨，基礎(chǔ)功能，加密等掐场。
2往扔，SSL握手協(xié)議贩猎，身份驗證，協(xié)商加密算法等萍膛。
問題：SSL的基礎(chǔ)是商家對客戶信息保密的承諾吭服。
身份的驗證：私鑰加密，公鑰解密蝗罗。如果驗證通過艇棕，就說明對方的確是擁有某私鑰的機構(gòu)。完成了身份的驗證串塑。
流程：
在得到證書申請者的一些必要信息（對象名稱沼琉，公鑰私鑰）之后，證書頒發(fā)者通過 SHA-256 哈希得到證書內(nèi)容的摘要桩匪，再用自己的私鑰給這份摘要加密刺桃，得到數(shù)字簽名。綜合已有的信息吸祟，生成分別包含公鑰和私鑰的兩個證書瑟慈。
客戶端證書：簽名是用私鑰加密過的摘要簽名。
信息完整性校驗：使用散列表hash方法屋匕，計算文件的hash葛碧，文件有最微小的改動，對應(yīng)hash也會變化过吻。這個過程是不可逆的进泼，也就是說得到hash值，無法得到原文纤虽。hash值相同乳绕，不能說明兩者文件相同。一般使用MD5和SHA1計算逼纸。應(yīng)用與數(shù)字簽名洋措。
RSA：一種非對稱加密方法。有配對的私鑰和公鑰杰刽，對一段數(shù)據(jù)而言菠发，加密后的數(shù)據(jù)只有用對應(yīng)的解密鑰匙解密。一般公鑰加密贺嫂，私鑰解密滓鸠。如果私鑰不泄露，那么就可以假定是安全的第喳。
1糜俗，如果有第三方解獲了公鑰，把公鑰破解了，得到私鑰悠抹，豈不是信息就破解了嗎寞射？
就目前而言，最大的破解的RSA長度為768锌钮，1024以上的是極為安全的。
2引矩，SSL握手之后梁丘，雙方使用的是協(xié)商好的對稱密碼，那萬一第三方破解了這個密碼旺韭，那豈不是信息都不安全了嗎：
數(shù)字簽名 就是使用個人私密和加密算法加密的摘要和報文氛谜，是私人性的。http://blog.csdn.net/oscar999/article/details/9364101
數(shù)字證書：目的区端，為了杜絕拿到的公鑰是偽造的值漫。
鮑勃使用了自己的私鑰為了給妻子寫信，妻子使用了鮑勃的公鑰揭秘郵件织盼，原來是好好的杨何，正常的×ち冢可是最近好像不太對勁危虱。可能是哪個壞人把“邪惡公鑰”裝在了鮑勃妻子的電腦上了唐全，這樣壞人就有可能冒充鮑勃和鮑勃的妻子通信了埃跷。這下麻煩大了。咋辦呢邮利？
鮑勃妻子可是個聰明的人啊弥雹，它找到了CA機構(gòu)，讓CA使用自己的私鑰加密了老公的公鑰和其他一些信息延届，形成了一個數(shù)字證書剪勿。
下次，鮑勃寫信呢方庭，就把這張通過CA認證的數(shù)字證書也發(fā)給了妻子窗宦，而妻子使用CA的公鑰（這個是公開的），解開數(shù)字證書二鳄，得到老公真實的公鑰赴涵。然后就能證明"數(shù)字簽名"是否真的是鮑勃簽的（簽名是老公用自己的私鑰加密的），如果壞人企圖再次欺騙鮑勃老婆订讼，就得過CA的關(guān)髓窜，這點貌似比較難啊！
總結(jié)：鮑勃和妻子都要信任CA機構(gòu)寄纵。
? ? ? ? ? ? CA也會出問題鳖敷，發(fā)生偽造的事情。
鮑勃寫信以后包括三方面：
（1）簽名：目的程拭，確認信件沒有被修改定踱。
（2）證書。目的恃鞋，確認公鑰是否真的屬于對方崖媚。因為有可能有人偷偷的在你電腦上替換了壞人的公鑰，給你發(fā)信件恤浪。這種情況下畅哑，你永遠都沒有可能解開真正的信息了。而證書因為引入了CA水由，使得即使有人偷偷的在你電腦上替換了壞人的公鑰情況下荠呐，你依然使用CA的公鑰去解析信件的公鑰（信件的公鑰被CA的私鑰加密過），這樣壞人的證書是通不過驗證的砂客。除非CA那里出了問題泥张。
（3）信件內(nèi)容。
所謂的長連接／短連接 并非真正的連接鞠值，而是指兩端TCP的“連接狀態(tài)”圾结。
TCP窗口：兩端的緩沖區(qū)
https：http + security（SSL層《》）
https作用：（1）信息在傳輸過程中的安全性，監(jiān)聽到也沒法破解 齿诉；第三方篡改數(shù)據(jù)也沒有了意義筝野。
（2）信息的接受源：確認客戶端和服務(wù)器的真實性，不是釣魚網(wǎng)站粤剧。
TCP與UDP的區(qū)別：
UDP－》不保證數(shù)據(jù)可以傳到目的地歇竟。
TCP有超時和重發(fā)機制，保證數(shù)據(jù)可以完整的傳輸抵恋。
TCP心跳檢測：目的焕议，節(jié)約不必要的TCP半連接，因為TCP打開了就不會主動關(guān)閉弧关，這樣的話就會浪費許多的連接盅安。如果不關(guān)掉就太浪費了。
長連接之所以可以長連接世囊，是因為TCP端口的狀態(tài)是某種狀態(tài)（ESTABLISHED）别瞭，短連接之所以為短連接，是因為改變了端口的狀態(tài)（CLOSED）株憾。
端口號表示不同的應(yīng)用程序
TCP報文段的到達也可能會失序蝙寨。如果必要,T C P將 對 收 到 的 數(shù) 據(jù) 進 行 重 新 排 序.TCP窗口就是緩存區(qū)晒衩。
網(wǎng)關(guān)：轉(zhuǎn)換不同網(wǎng)絡(luò)協(xié)議的服務(wù)器程序。
路由器：連接不同的網(wǎng)絡(luò)墙歪，可以認為是網(wǎng)關(guān)听系。
NSURLSession：
NSURLSession和NSURLConnection區(qū)別：
（1）Sessions are Containers：https://code.tutsplus.com/tutorials/networking-with-nsurlsession-part-1--mobile-21394
網(wǎng)絡(luò)認證：“Authorization-AccessToken”網(wǎng)絡(luò)認證；
OAuth：一個關(guān)于授權(quán)（authorization）的開放網(wǎng)絡(luò)標(biāo)準(zhǔn)虹菲，在全世界得到廣泛應(yīng)用靠胜，目前的版本是2.0版。
關(guān)鍵點：第三方APP（客戶端毕源，比如自己開發(fā)的APP）浪漠，資源服務(wù)器，資源擁有者（比如脑豹，微信）
1，APPID衡查，APPSecret：第三方APP（客戶端）的信息瘩欺。
臨時票據(jù)：資源方返回的用于獲取access_token的臨時票據(jù)。
redirect_url（由客戶端指定）：資源擁有者確認授權(quán)后拌牲，返回的url俱饿，后期該url提取access_token，返回給客戶端塌忽。
grant_type：授權(quán)的類型拍埠，有 更新令牌 各種模式等。
最終的目的：得到一個access_token土居，它是第三方APP獲取用戶基本數(shù)據(jù)資源或幫助用戶實現(xiàn)基本操作的憑證枣购，
第三方可以獲取到用戶的接口調(diào)用憑證（access_token），通過access_token可以進行微信開放平臺授權(quán)關(guān)系接口調(diào)用擦耀，從而可實現(xiàn)獲取微信用戶基本開放信息和幫助用戶實現(xiàn)基礎(chǔ)開放功能等棉圈。
application/x-www-form-urlencoded
Base64編碼可用于在HTTP環(huán)境下傳遞較長的標(biāo)識信息。
IOS網(wǎng)絡(luò)請求：
Lost connection to background transfer service
REST API:RESTful架構(gòu)眷蜓，就是目前最流行的一種互聯(lián)網(wǎng)軟件架構(gòu)分瘾。
SSO單點登錄：SSO是在多個應(yīng)用系統(tǒng)中，用戶只需要登錄一次就可以訪問所有相互信任的應(yīng)用系統(tǒng)吁系。它包括可以將這次主要的登錄映射到其他應(yīng)用中用于同一個用戶的登錄的機制德召。SSO是一種統(tǒng)一認證和授權(quán)機制，指訪問同一服務(wù)器不同應(yīng)用中的受保護資源的同一用戶汽纤，只需要登錄一次上岗，即通過一個應(yīng)用中的安全驗證后，再訪問其他應(yīng)用中的受保護資源時蕴坪，不再需要重新登錄驗證液茎。
http://www.mamicode.com/info-detail-909227.html
IP知識：
1，私有地址：局域網(wǎng)的IP普遍是192.168開頭，例如我的IP地址就是192.168.199.xxx捆等，這只是局域網(wǎng)地址滞造，不是公網(wǎng)地址，所以這需要路由器轉(zhuǎn)換栋烤。
2谒养，NAT：網(wǎng)絡(luò)地址轉(zhuǎn)換，將其本地地址轉(zhuǎn)換成全球IP地址明郭，才能和因特網(wǎng)連接买窟。
