網絡編程就是在兩個或兩個以上的設備(例如計算機)之間傳輸數據。html
程序員所做的事情就是把數據發送到指定的位置,或者接收到指定的數據,這個就是狹義的網絡編程範疇。java
在發送和接收數據時,大部分的程序設計語言都設計了專門的API實現這些功能,程序員只須要調用便可。git
網絡編程技術是當前一種主流的編程技術,隨着聯網趨勢的逐步加強以及網絡應用程序的大量出現,因此在實際的開發中網絡編程技術得到了大量的使用。程序員
網絡編程的實質就是兩個(或多個)設備(例如計算機)之間的數據傳輸。編程
按照計算機網絡的定義,經過必定的物理設備將處於不一樣位置的計算機鏈接起來組成的網絡,這個網絡中包含的設備有:計算機、路由器、交換機等等。瀏覽器
路由器和交換機組成了核心的計算機網絡,計算機只是這個網絡上的節點以及控制等,經過光纖、網線等鏈接將設備鏈接起來,從而造成了一張巨大的計算機網絡。服務器
網絡最主要的優點在於共享:共享設備和數據。網絡
爲了可以方便的識別網絡上的每一個設備,網絡中的每一個設備都會有一個惟一的數字標識,這個就是IP地址。在計算機網絡中,如今命名IP地址的規定是IPv4協議,該協議規定每一個IP地址由4個0-255之間的數字組成。併發
可是因爲IP地址不容易記憶,因此爲了方便記憶,有創造了另一個概念——域名(Domain Name),例如sohu.com等。一個IP地址能夠對應多個域名,一個域名只能對應一個IP地址。socket
在網絡中傳輸的數據,所有是以IP地址做爲地址標識,因此在實際傳輸數據之前須要將域名轉換爲IP地址,實現這種功能的服務器稱之爲DNS服務器,也就是通俗的說法叫作域名解析。
當DNS服務器正常工做時,使用IP地址或域名均可以很方便的找到計算機網絡中的某個設備,例如服務器計算機。
當DNS不正常工做時,只能經過IP地址訪問該設備。因此IP地址的使用要比域名通用一些。
有了端口的概念之後,一個計算機上能夠併發運行多個網絡程序,而不會在互相之間產生干擾。
在硬件上規定,端口的號碼必須位於0-65535之間,每一個端口惟一的對應一個網絡程序,一個網絡程序可使用多個端口。
網絡編程就是兩個或多個設備之間的數據交換,其實更具體的說,網絡編程就是兩個或多個程序之間的數據交換,和普通的單機程序相比,網絡程序最大的不一樣就是須要交換數據的程序運行在不一樣的計算機上,這樣就形成了數據交換的複雜。雖然經過IP地址和端口能夠找到網絡上運行的一個程序,可是若是須要進行網絡編程,則還須要瞭解網絡通信的過程。
網絡通信基於「請求-響應」模型。
在網絡通信中,第一次主動發起通信的程序被稱做客戶端(Client)程序,簡稱客戶端,而在第一次通信中等待鏈接的程序被稱做服務器端(Server)程序,簡稱服務器。一旦通信創建,則客戶端和服務器端徹底同樣,沒有本質的區別。
使用C/S結構的程序,在開發時須要分別開發客戶端和服務器端,這種結構的優點在於因爲客戶端是專門開發的,因此根據須要實現各類效果,專業點說就是表現力豐富,而服務器端也須要專門進行開發。可是這種結構也存在着不少不足,例如通用性差,幾乎不能通用等,也就是說一種程序的客戶端只能和對應的服務器端通信,而不能和 其它服務器端通信,在實際維護時,也須要維護專門的客戶端和服務器端,維護的壓力比較大。
使用B/S結構的程序,在開發時只須要開發服務器端便可,這種結構的優點在於開發的壓力比較小,不須要維護客戶端。可是這種結構也存在着不少不足,例如瀏覽器的限制比較大,表現力不強,沒法進行系統級操做等。
總之C/S結構和B/S結構是如今網絡編程中常見的兩種結構,B/S結構其實也就是一種特殊的C/S結構。
P2P(Point to Point)程序,常見的如BT、電驢等。P2P程序是一種特殊的程序,應該一個P2P程序中既包含客戶端程序,也包含服務器端程序,例如BT,使用客戶端程序部分鏈接其它的種子(服務器端),而使用服務器端向其它的BT客戶端傳輸數據。
那麼如何來編寫協議格式呢?答案是隨意。只要按照這種協議格式可以生成惟一的編碼,按照該編碼能夠惟一的解析出發送數據的內容便可。也正由於各個網絡程序之間協議格式的不一樣,因此才致使了客戶端程序都是專用的結構。
在實際的網絡程序編程中,最麻煩的內容就是協議的設計以及協議的生產和解析,這個纔是網絡編程中最核心的內容。
一、 TCP(傳輸控制協議)方式 二、 UDP(用戶數據報協議)方式
在網絡通信中,TCP方式就相似於撥打電話,使用該種方式進行網絡通信時,須要創建專門的虛擬鏈接,而後進行可靠的數據傳輸,若是數據發送失敗,則客戶端會自動重發該數據。而UDP方式就相似於發送短信,使用這種方式進行網絡通信時,不須要創建專門的虛擬鏈接,傳輸也不是很可靠,若是發送失敗則客戶端沒法得到。
這兩種傳輸方式都是實際的網絡編程中進行使用,重要的數據通常使用TCP方式進行數據傳輸,而大量的非核心數據則都經過UDP方式進行傳遞,在一些程序中甚至結合使用這兩種方式進行數據的傳遞。
因爲TCP須要創建專用的虛擬鏈接以及確認傳輸是否正確,因此使用TCP方式的速度稍微慢一些,並且傳輸時產生的數據量要比UDP稍微大一些。
不管使用TCP方式仍是UDP方式進行網絡通信,網絡編程都是由客戶端和服務器端組成。固然,B/S結構的編程中只須要實現服務器端便可。
客戶端網絡編程的第一步都是創建網絡鏈接。在創建網絡鏈接時須要指定鏈接到的服務器的IP地址和端口號,創建完成之後,會造成一條虛擬的鏈接,後續的操做就能夠經過該鏈接實現數據交換了。
- 鏈接創建之後,就能夠經過這個鏈接交換數據了。交換數據嚴格按照請求響應模型進行,由客戶端發送一個請求數據到服務器,服務器反饋一個響應數據給客戶端,若是客戶端不發送請求則服務器端就不響應。 - 根據邏輯須要,能夠屢次交換數據,可是仍是必須遵循請求響應模型。
在數據交換完成之後,關閉網絡鏈接,釋放程序佔用的端口、內存等系統資源,結束網絡編程。
- 服務器端屬於被動等待鏈接,因此服務器端啓動之後,不須要發起鏈接,而只須要監聽本地計算機的某個固定端口便可。 - 這個端口就是服務器端開放給客戶端的端口,服務器端程序運行的本地計算機的IP地址就是服務器端程序的IP地址。
- 當客戶端鏈接到服務器端時,服務器端就能夠得到一個鏈接,這個鏈接包含客戶端的信息,例如客戶端IP地址等等,服務器端和客戶端也經過該鏈接進行數據交換。 - 通常在服務器端編程中,當得到鏈接時,須要開啓專門的線程處理該鏈接,每一個鏈接都由獨立的線程實現。
- 服務器端經過得到的鏈接進行數據交換。服務器端的數據交換步驟是首先接收客戶端發送過來的數據,而後進行邏輯處理,再把處理之後的結果數據發送給客戶端。簡單來講,就是先接收再發送,這個和客戶端的數據交換數序不一樣。 - 其實,服務器端得到的鏈接和客戶端鏈接是同樣的,只是數據交換的步驟不一樣。 - 固然,服務器端的數據交換也是能夠屢次進行的。 - 在數據交換完成之後,關閉和客戶端的鏈接。
當服務器程序關閉時,須要關閉服務器端,經過關閉服務器端使得服務器監聽的端口以及佔用的內存能夠釋放出來,實現了鏈接的關閉。
首先來介紹一個基礎的網絡類——InetAddress類。該類的功能是表明一個IP地址,而且將IP地址和域名相關的操做方法包含在該類的內部。
eg:關於該類的使用,下面經過一個基礎的代碼示例演示該類的使用。
按照前面的介紹,網絡通信的方式有TCP和UDP兩種,其中TCP方式的網絡通信是指在通信的過程當中保持鏈接。
在Java語言中,對於TCP方式的網絡編程提供了良好的支持,在實際實現時,以java.net.Socket
類表明客戶端鏈接,以java.net.ServerSocket
類表明服務器端鏈接。
eg:在客戶端網絡編程中,首先須要創建鏈接,在Java API中以java.net.Socket
類的對象表明網絡鏈接,因此創建客戶端網絡鏈接,也就是建立Socket類型的對象,該對象表明網絡鏈接。
Socket socket1 = new Socket(「192.168.1.103」,10000); Socket socket2 = new Socket(「www.sohu.com」,80); 上面的代碼中,socket1實現的是鏈接到IP地址是192.168.1.103的計算機的10000號端口,而socket2實現的是鏈接到域名是www.sohu.com的計算機的80號端口。若是創建鏈接時,本機網絡不通,或服務器端程序未開啓,則會拋出異常。
eg:從鏈接中得到輸入流和輸出流,而後將須要發送的數據寫入鏈接對象的輸出流中,在發送完成之後從輸入流中讀取數據。
OutputStream os = socket1.getOutputStream(); //得到輸出流 InputStream is = socket1.getInputStream(); //得到輸入流 上面的代碼中,分別從socket1這個鏈接對象得到了輸出流和輸入流對象,在整個網絡編程中,後續的數據交換就變成了IO操做,也就是遵循「請求-響應」模型的規定,先向輸出流中寫入數據,這些數據會被系統發送出去,而後在從輸入流中讀取服務器端的反饋信息,這樣就完成了一次數據交換過程,固然這個數據交換過程能夠屢次進行。
eg:最後當數據交換完成之後,關閉網絡鏈接,釋放網絡鏈接佔用的系統端口和內存等資源,完成網絡操做。
socket1.close();
eg:向服務器端發送一個字符串「Hello」,並將服務器端的反饋顯示到控制檯,數據交換隻進行一次,當數據交換進行完成之後關閉網絡鏈接,程序結束。
eg:實現服務器端監聽的代碼:
ServerSocket ss = new ServerSocket(10000);
eg:實現得到鏈接的代碼是:
Socket socket = ss.accept();
eg:在服務器端通訊完成之後,關閉服務器端鏈接。實現的代碼爲:
ss.close();
一、如何複用Socket鏈接?
eg:實現創建一次鏈接,進行屢次數據交換呢。其實很簡單,創建鏈接之後,將數據交換的邏輯寫到一個循環中就能夠了。這樣只要循環不結束則鏈接就不會被關 閉。按照這種思路,能夠改造一下上面的代碼,讓該程序能夠在創建鏈接一次之後,發送三次數據,固然這裏的次數也能夠是屢次。
二、如何使服務器端支持多個客戶端同時工做?
eg:MulThreadSocketServer類實現服務器端控制,實現接收客戶端鏈接,而後開啓專門的邏輯線程處理該鏈接,LogicThread類實現對於一個客戶端鏈接的邏輯處理,將處理的邏輯放置在該類的run方法中。
1.l DatagramSocket DatagramSocket類實現「網絡鏈接」,包括客戶端網絡鏈接和服務器端網絡鏈接。雖然UDP方式的網絡通信不須要創建專用的網絡鏈接,可是畢竟仍是須要發送和接收數據,DatagramSocket實現的就是發送數據時的發射器,以及接收數據時的監聽器的角色。類比於TCP中的網絡鏈接,該類既能夠用於實現客戶端鏈接,也能夠用於實現服務器端鏈接。 2.l DatagramPacket DatagramPacket類實現對於網絡中傳輸的數據封裝,也就是說,該類的對象表明網絡中交換的數據。在UDP方式的網絡編程中,不管是須要發送的數據仍是須要接收的數據,都必須被處理成DatagramPacket類型的對象,該對象中包含發送到的地址、發送到的端口號以及發送的內容等。其實DatagramPacket類的做用相似於現實中的信件,在信件中包含信件發送到的地址以及接收人,還有發送的內容等,郵局只須要按照地址傳遞便可。在接收數據時,接收到的數據也必須被處理成DatagramPacket類型的對象,在該對象中包含發送方的地址、端口號等信息,也包含數據的內容。和TCP方式的網絡傳輸相比,IO編程在UDP方式的網絡編程中變得不是必須的內容,結構也要比TCP方式的網絡編程簡單一些。
UDP客戶端編程涉及的步驟也是4個部分:創建鏈接、發送數據、接收數據和關閉鏈接。
因爲服務器端的端口須要固定,因此通常在創建服務器端鏈接時,都指定端口號。
接着服務器端就開始接收客戶端發送過來的數據,其接收的方法和客戶端接收的方法一直,其中receive方法的做用相似於TCP方式中accept方法的做用,該方法也是一個阻塞方法,其做用是接收數據。
eg:UDP網絡編程的基本使用。實現將客戶端程序的系統時間發送給服務器端,服務器端接收到時間之後,向客戶端反饋字符串「OK」。
網絡協議是指對於網絡中傳輸的數據格式的規定。
eg:實現的功能是質數判斷,程序實現的功能爲客戶端程序接收用戶輸入的數字,而後將用戶輸入的內容發送給服務器端,服務器端判斷客戶端發送的數字是不是質數,並將判斷的結果反饋給客戶端,客戶端根據服務器端的反饋顯示判斷結果。
一、 客戶端程序功能: a) 接收用戶控制檯輸入 b) 判斷輸入內容是否合法 c) 按照協議格式生成發送數據 d) 發送數據 e) 接收服務器端反饋 f) 解析服務器端反饋信息,並輸出 二、 服務器端程序功能: a) 接收客戶端發送數據 b) 按照協議格式解析數據 c) 判斷數字是不是質數 d) 根據判斷結果,生成協議數據 e) 將數據反饋給客戶端
eg:當客戶端第一次鏈接到服務器端時,服務器端生產一個【0,50】之間的隨機數字,而後客戶端輸入數字來猜該數字,每次客戶端輸入數字之後,發送給服務器端,服務器端判斷該客戶端發送的數字和隨機數字的關係,並反饋比較結果,客戶端總共有5次猜的機會,猜中時提示猜中,當輸入」quit」時結束程序。
- 客戶端程序功能列表: 一、 接收用戶控制檯輸入 二、 判斷輸入內容是否合法 三、 按照協議格式發送數據 四、 根據服務器端的反饋給出相應提示 - 服務器端程序功能列表: 一、 接收客戶端發送數據 二、 按照協議格式解析數據 三、 判斷髮送過來的數字和隨機數字的關係 四、 根據判斷結果生產協議數據 五、 將生產的數據反饋給客戶端
問題1:
當DNS服務器正常工做時,使用IP地址或域名均可以很方便的找到計算機網絡中的某個設備,例如服務器計算機。那當DNS不正常工做時該怎麼樣?問題1解決方案:
當DNS不正常工做時只能經過IP地址訪問該設備。因此IP地址的使用要比域名通用一些。問題2:
客戶端的編程主要由哪三個步驟實現?
問題2解決方案:
無
此次與實驗有關的考試做答的不是很好,感受並無很好地掌握。之後會多多查看老師發的文件,去學習。
教材學習中的問題和解決過程, 一個問題加1分
代碼調試中的問題和解決過程, 一個問題加1分
基於評分標準,我給本博客打分:XX分。得分狀況以下:xxx
使用C/S結構的程序,在開發時須要分別開發客戶端和服務器端,這種結構的優點在於因爲客戶端是專門開發的,因此根據須要實現各類效果,專業點說就是表現力豐富,而服務器端也須要專門進行開發。可是這種結構也存在着不少不足,例如通用性差,幾乎不能通用等,也就是說一種程序的客戶端只能和對應的服務器端通信,而不能和 其它服務器端通信,在實際維護時,也須要維護專門的客戶端和服務器端,維護的壓力比較大。
使用B/S結構的程序,在開發時只須要開發服務器端便可,這種結構的優點在於開發的壓力比較小,不須要維護客戶端。可是這種結構也存在着不少不足,例如瀏覽器的限制比較大,表現力不強,沒法進行系統級操做等。
上週博客互評狀況(只要連接,具體點評放相應博客下)
經過前面幾周的學習,java的核心知識與難點以前都已經學完了,後面的章節大概都是介紹一些類的應用。在不斷的學習中,我也在不斷的尋找適合本身的學習方法。平時本身要主動敲代碼,主動發現問題,提升學習效率。
代碼行數(新增/累積) | 博客量(新增/累積) | 學習時間(新增/累積) | 重要成長 | |
---|---|---|---|---|
目標 | 5000行 | 30篇 | 400小時 | |
第一週 | 5/5 | 1/4 | 20/20 | |
第二週 | 140/145 | 1/5 | 18/38 | |
第三週 | 330/451 | 1/6 | 16/54 | |
第四周 | 578/1038 | 1/7 | 18/72 | |
第五週 | 774/1472 | 1/8 | 18/90 | |
第六週 | 1592/3064 | 1/9 | 18/108 | |
第七週 | 1034/4098 | 2/11 | 22/130 | |
第八週 | 613/4711 | 1/12 | 20/150 | |
第九周 | 2924/5574 | 2/14 | 16/166 | |
第十週 | 984/6558 | 1/15 | 20/186 |
嘗試一下記錄「計劃學習時間」和「實際學習時間」,到期末看看能不能改進本身的計劃能力。這個工做學習中很重要,也頗有用。
耗時估計的公式
:Y=X+X/N ,Y=X-X/N,訓練次數多了,X、Y就接近了。
計劃學習時間:22小時
實際學習時間:20小時
改進狀況:無
(有空多看看現代軟件工程 課件
軟件工程師能力自我評價表)