網絡——性能調優

Socket是應⽤用層與TCP/IP協議族通訊的中間軟件抽象層,它是⼀一組接⼝口。在設計模式中,Socket其實就是 ⼀一個⻔門⾯面模式,它把複雜的TCP/IP協議族隱藏在Socket接⼝口後⾯面,對⽤用戶來講,⼀一組簡單的接⼝口就是所有,讓 Socket去組織數據,以符合指定的協議。

⼀一個⽣生活中的場景。你要打電話給⼀一個朋友,先撥號,朋友聽到電話鈴聲後提起電話,這時你和你的朋友就 建⽴立起了鏈接,就能夠講話了。等交流結束,掛斷電話結束這次交談。

先從服務器端提及。1>服務器端先初始化Socket,而後與端⼝口綁定(bind),對端⼝口進⾏行監聽(listen),調 ⽤用accept阻塞,等待客戶端鏈接。2>在這時若是有個客戶端初始化⼀一個Socket,而後鏈接服務器(connect),3>若是 鏈接成功,這時客戶端與服務器端的鏈接就建⽴立了。客戶端發送數據請求,服務器端接收請求並處理請求,而後鏈接成功,這時客戶端與服務器端的鏈接就建⽴立了。客戶端發送數據請求,服務器端接收請求並處理請求,而後

arc=send(fd,szText,cnt,0);

把迴應數據發送給客戶端,客戶端讀取數據,最後關閉鏈接,⼀一次交互結束。

在客戶端輸⼊入服務器端的IP地址和發送的數據,而後按發送按鈕,服務器端接收到數據,而後迴應客戶端。 客戶端讀取回應的數據,顯⽰示在界⾯面上。

在服務器端,主要是啓動Socket和監聽線程。

服務器端⼀一直在監聽是否有客戶端鏈接,若有鏈接,處理客戶端的請求,給出迴應,而後繼續監聽。

客戶端:

蘋果iso開發： socket tcp/ip 的通信

使用方法以下：

一、建立工程。

二、把AsyncSocket添加到項目中。

三、添加CFNetwork.framework到工程中。

四、實現測試類：

#import <UIKit/UIKit.h>

#import "AsyncSocket.h"

@interface iphone_socketViewController : UIViewController {  

   AsyncSocket *asyncSocket; }  

@end

IOS socket基於tcp/udp的通訊

分類： ios開發 2013-12-03 15:10 1399人閱讀 評論(0) 收藏 舉報

ios通訊socket蘋果

網絡上已經有編寫好的開源類庫GCDAsyncSocket 和GCDAsyncUdpSocket  這是GCD版的  比AsyncSocket 和AsyncUdpSocket估計要好用點 用法也很簡單，跟http很相似  只要指定服務器的ip和端口 而後再實現各類回調就行，原生態實現正在摸索。。。。。socket 默認狀況下就是採用TCP協議，建立以後通訊雙方的socket會一直保持鏈接，除非手動close或由於網絡緣由close，因此，此種情況對服務器而 言是有必定資源消耗的，這種模式只適應與對服務器小規模的訪問，特別是對於實時性很高的應用，如視頻直播、呼叫系統等，而http通常都是短鏈接的，一次 請求完以後客戶端便會於服務端端開鏈接
   http是凌駕於socket之上的高級協議，而socket是比較底層的通信方式，只是創建了一個鏈接通道，具體上面傳輸什麼樣的數據，按照什麼格式傳輸，須要你本身定義，因此這就須要從新編寫定義服務端與客戶端的所應遵循的規定，而http已經被前人們定義使用過了

先去github的網站下載最新的包，而後先看看介紹。寫的比較詳細了

https://github.com/robbiehanson/CocoaAsyncSocket/wiki/Intro_GCDAsyncSocket

網上不少都是老版本的帖子。官方已經推出了GCDAsyncSocket來代替之前老的AsyncSocket。

個人項目是no-ARC的，這個框架只有arc的版本。因此引入GCDAsyncSocket的.h和.m文件後，修改xcode中項目的屬性。

 

1）targets中「build settings」中找到Compiler for c／c＋＋／Objective－c的選項。改成Apple LLVM compiler 3.0 只要是3.0或以上就能夠

2）在「build phases」中「compile sources」中找到GCDAsyncSocket.m，增長參數-fobj-arc

3）引入GCDAsyncSocket所須要的框架，CFNetwork和security這兩個

通信http，TCP/IP與socket之間的區別

一、TCP/IP鏈接

  手機可以使用聯網功能是由於手機底層實現了TCP/IP協議，可使手機終端經過無線網絡創建TCP鏈接。TCP協議能夠對上層網絡提供接口，使上層網絡數據的傳輸創建在「無差異」的網絡之上。創建起一個TCP鏈接須要通過「三次握手」：

第一次握手：客戶端發送syn包(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鏈接的請求，斷開過程須要通過「四次握手」（過程就不細寫了，就是服務器和客戶端交互，最終肯定斷開）.

 

二、HTTP鏈接

HTTP協議即超文本傳送協議(Hypertext Transfer Protocol )，是Web聯網的基礎，也是手機聯網經常使用的協議之一，HTTP協議是創建在TCP協議之上的一種應用。

HTTP鏈接最顯著的特色是客戶端發送的每次請求都須要服務器回送響應，在請求結束後，會主動釋放鏈接。從創建鏈接到關閉鏈接的過程稱爲「一次鏈接」。

3.1套接字（socket）概念

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

 

3.2 創建socket鏈接

 創建Socket鏈接至少須要一對套接字，其中一個運行於客戶端，稱爲ClientSocket ，另外一個運行於服務器端，稱爲ServerSocket 。

 

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

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

 

 

 

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

 

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

 

四、SOCKET鏈接與TCP/IP鏈接

建立Socket鏈接時，能夠指定使用的傳輸層協議，Socket能夠支持不一樣的傳輸層協議（TCP或UDP），當使用TCP協議進行鏈接時，該Socket鏈接就是一個TCP鏈接。

 
五、Socket鏈接與HTTP鏈接

不少狀況下，須要服務器端主動向客戶端推送數據，保持客戶端與服務器數據的實時與同步。此時若雙方創建的是Socket鏈接，服務器就能夠直接將數據傳送給客戶端；若雙方創建的是HTTP鏈接，則服務器須要等到客戶端發送一次請求後才能將數據傳回給客戶端，所以，客戶端定時向服務器端發送鏈接請求，不只能夠保持在線，同時也是在「詢問」服務器是否有新的數據，若是有就將數據傳給客戶端。

 

http協議是應用層的協義 

一個是發動機(Socket),提供了網絡通訊的能力 
一個是轎車(Http)，提供了具體的方式 

 

兩個計算機之間的交流無非是兩個端口之間的數據通訊,具體的數據會以什麼樣的形式展示`是以不一樣的應用層協議來定義的`如HTTP`FTP`... 

socket是對端口通訊開發的工具,它要更底層一些 .

 

get和post這是http協議的兩種方法，另外還有head, delete等
這兩種方法有本質的區別，get只有一個流，參數附加在url後，大小個數有嚴格限制且只能是字符串。post的參數是經過另外的流傳遞的，不經過url，因此能夠很大，也能夠傳遞二進制數據，如文件的上傳。
在servlet開發中，

TCP/IP、Http、Socket的區別

　　經過初步的瞭解，我知道IP協議對應於網絡層，TCP協議對應於傳輸層，而HTTP協議對應於應用層，

　

」

　　而咱們平時說的最多的socket是什麼呢，實際上socket是對TCP/IP協議的封裝，Socket自己並非協議，而是一個調用接口(API)。

　　經過Socket，咱們才能使用TCP/IP協議。

　　實際上，Socket跟TCP/IP協議沒有必然的聯繫。

　　Socket編程接口在設計的時候，就但願也能適應其餘的網絡協議。

　　因此說，Socket的出現只是使得程序員更方便地使用TCP/IP協議棧而已，是對TCP/IP協議的抽象，

　　從而造成了咱們知道的一些最基本的函數接口，好比create、listen、connect、accept、send、read和write等等。

　　網絡有一段關於socket和TCP/IP協議關係的說法比較容易理解：

　　「TCP/IP只是一個協議棧，就像操做系統的運行機制同樣，必需要具體實現，同時還要提供對外的操做接口。

　

　　CSDN上有個比較形象的描述：HTTP是轎車，提供了封裝或者顯示數據的具體形式;Socket是發動機，提供了網絡通訊的能力。

　　實際上，傳輸層的TCP是基於網絡層的IP協議的，而應用層的HTTP協議又是基於傳輸層的TCP協議的，而Socket自己不算是協議，就像上面所說，它只是提供了一個針對TCP或

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

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

　　二、客戶端請求：指客戶端的套接字提出鏈接請求，要鏈接的目標是服務器端的套接字。

　　爲此，客戶端的套接字必須首先描述它要鏈接的服務器的套接字，指出服務器端套接字的地址和端口號，而後就向服務器端套接字提出鏈接請求。

　　三、鏈接確認：當服務器端套接字監聽到或者說接收到客戶端套接字的鏈接請求時，就響應客戶端套接字的請求，創建一個新的線程，把服務器端套接字的描述發給客戶端，一旦客戶端確認了此描述，雙方就正式創建鏈接。

　　而服務器端套接字繼續處於監聽狀態，繼續接收其餘客戶端套接字的鏈接請求。

　　3、HTTP連接的特色

　　HTTP協議即超文本傳送協議(Hypertext Transfer Protocol )，是Web聯

　　4、TCP和UDP的區別(考得最多。。快被考爛了我以爲- -\\)

　　一、TCP是面向連接的，雖說網絡的不安全不穩定特性決定了多少次握手都不能保證鏈接的可靠性，但TCP的三次握手在最低限度上(實際上也很大程度上保證了)保證了鏈接的可靠性;

　　而UDP不是面向鏈接的，UDP傳送數據前並不與對方創建鏈接，對接收到的數據也不發送確認信號，發送端不知道數據是否會正確接收，固然也不用重發，因此說UDP是無鏈接的、不可靠的一種數據傳輸協議。

　　二、也正因爲1所說的特色，使得UDP的開銷更小數據傳輸速率更高，由於沒必要進行收發數據的確認，因此UDP的實時性更好。

　　知道了TCP和UDP的區別，就不難理解爲什麼採用TCP傳輸協議的MSN比採用UDP的QQ傳輸文件慢了，但並不能說QQ的通訊是不安全的，

　　由於程序員能夠手動對UDP的數據收發進行驗證，好比發送方對每一個數據包進行編號而後由接收方進行驗證啊什麼的，

　　即便是這樣，UDP由於在底層協議的封裝上沒有采用相似TCP的「三次握手」而實現了TCP所沒法達到的傳輸效率。

iOS應用是很是注重用戶體驗的，不光是要求界面設計合理美觀，也要求各類UI的反應靈敏，我相信你們對那種一拖就卡卡卡的 TableView 應用沒什麼好印象。還記得12306麼，那個速度，相信你們都受不了。爲了提升 iOS 的運行速度，下面我將拋磚引玉介紹一些我實踐過的用來提供iOS程序運行效率的方法，與你們分享，但願能獲得更多的反饋和建議。

1，計算代碼運行時間：相信數據，不要太相信感受。

2，善用性能分析工具。

4  不要使用太多的Xib  xib編譯速度慢,有個將xib轉化爲代碼的過程

5.  對於 TableView，重用 cell；減小 cell 初始化的工做量，延遲裝載；

6. 在線程中使用 autoreleasepool。

7，將一些不過重要的任務放在 idle 時運行。

8，不要在 viewWillAppear 中作費時的操做。

9，使用多線程來延遲加載資源。佔位,異步,主線程

10  利用 cache 空間換時間。cache 是一種常見的空間換時間的提供性能的收到，能夠用在至關多的場合。

 

 

iOS6,7的時間

1.按照傳統  新版IOS會隨着新版IOS設備一塊兒出現，也就是下個月發佈的全新iphone，可是在6月蘋果召開大會的時候已經放出了ios6的bate版，若是你有開發者帳號，即可以更新到最新的測試版，若是沒有下個月也勢必能夠等到正式版IOS6

iOS6新特性

    每次ios大版本的更新，都會帶來一些新的東西，對開發者來講，有利有弊。 好處是，新增了不少新的屬性，控件和api，開發者權限更大了，能夠輕鬆實現更多的功能。弊端在於，可能廢除了一些舊的api接口，須要作更多的適配和兼 容。經過本身開發過程當中的一些經驗，查閱ios6 SDK以及參考網上一些文檔。 總結了下面這些關於ios6系統的新特性，方便你們在後續開發過程當中進行對比參考。

一  關於內存警告

  ios6中廢除了viewDidUnload，viewWillUnload這兩個系統回調， 收到內存警告時在didReceiveMemoryWarning中進行相關的處理。

二  關於屏幕旋轉

一樣ios6 廢除了shouldAutorotateToInterfaceOrientation這個旋轉屏幕的設置接口。 必須在兩個新接口中設置旋轉屬性:shouldAutorotate

supportedInterfaceOrientations

收到旋轉事件後的處理，一樣在willRotateToInterfaceOrientation,和didRotateFromInterfaceOrientation中進行。

三  UISwitch

ios6下,新增瞭如下幾個屬性，能夠設置開關的顏色以及背景圖

@property ( nonatomic ,  retain ) UIColor*tintColor;

@property ( nonatomic ,  retain ) UIColor*thumbTintColor;

@property ( nonatomic ,  retain ) UIImage*onImage;

@property ( nonatomic ,  retain )UIImage *offImage;

四  UINavigationBar

ios6新增了,設置陰影圖片的屬性

@property ( nonatomic , retain ) UIImage*shadowImage;

五 UIImage

能夠在ios6下設置圖片的scale比例尺寸了

+ (UIImage *)imageWithData:(NSData *)data scale:(CGFloat)scale;

- ( id )initWithData:(NSData *)data scale:(CGFloat)scale;

六  UIRefreshControl

以前蘋果官方是沒有現成的下拉刷新的控件，都是本身實現或者使用比較成熟的開源庫。  此次，ios6 蘋果加入了UIRefreshControl，配合UITableView直接實現下拉刷新。可是爲了保證兼容性， 仍是不推薦目前使用這個控件。 

七UICollectionView

全新的集合控件， 應用場景有相似照片牆，瀑布流等。Github裏以前已經有不少開源庫實現了這個控件的功能。

iOS7新特性

全新UI設計
iOS7最大的變化莫過於UI設計，也許你會說UI設計「這是設計師大大們應該關注的事情，不關開發者的事，咱們只須要替換圖片就好了」。那你就錯了。 UI的變化必然帶來使用習慣和方式的轉變，如何運用iOS7的UI，如何是本身的應用更切合新的系統，都是須要考慮的事情。另外值得注意的是，使用 iOS7 SDK（如今只有Xcode5預覽版提供）打包的應用在iOS7上運行時將會自動使用iOS7的新界面，因此原有應用可能須要對新界面進行重大調整。具體 的iOS7中所使用的UI元素的人際交互界面文檔，能夠從這裏找到（應該是須要開發者帳號才能看）。

簡單總結來講，以如今上手體驗看來新的UI變化改進有以下幾點：

1.狀態欄，導航欄和應用實際展現內容再也不界限：系統自帶的應用都再也不區分狀態欄和navigation bar，而是用統一的顏色力求簡潔。這也算是一種趨勢。

2.BarItem的按鈕所有文字化：這點作的至關堅定，全部的導航和工具條按鈕都取消了擬物化，原來的文字（好比「Edit」，「Done」之類）改成了簡單的文字，原來的圖標（好比新建或者刪除）也作了簡化。

3.程序打開加入了動畫：從主界面到圖標所在位置的一個放大，同時顯示應用的載入界面。

春風又綠加州岸，物是人非又一年。WWDC 2013 keynote落下帷幕，新的iOS開發旅程也由此開啓。在iOS7界面重大變革的背後，開發者們須要知道的又有哪些呢。同去年同樣，我會先簡單縱覽地介 紹iOS7中我我的認爲開發者須要着重關注和學習的內容，以後再陸續對本身感興趣章節進行探索。計劃繼承相似WWDC2012的筆記的形式，但願國內開發 者有所幫助。

 

 

最後
固然還有一些其餘小改動，包括MessageUI裏添加了附件按鈕，Xcode開始支持模塊了等等。完整的iOS7新特性列表能夠在這裏找到（暫時應該也 須要開發者帳號）。最後一個好消息是，蘋果放慢了廢棄API的速度，這個版本並無特別重要的API被標爲Deprecated，Cheers。
 

雖然ARC是與iOS5一同推出，可是因爲ARC的實現機制是在編譯期完成，因此使用ARC以後App仍然能夠支持iOS4.3。稍微須要注意的是，若是 要在ARC開啓的狀況下支持iOS4.3，須要將weak關鍵字換成 __unsafe_unretained，另外還有一些細節須要處理，在這裏我就不展開說了。