Android 基礎入門教程--筆記

時間 2019-11-13

原文原文鏈接

引言：做爲APP測試人員，瞭解Android APP 開發的一些基礎認識是很好的。

http://www.runoob.com/w3cnote/android-tutorial-system-architecture-analysis.htmlhtml

1.解決兼容問題

那麼多的系統版本，咱們開發的時候要針對哪一個版本進行開發？這就是做爲一個Android必須面對的Android的"碎片化"問題了，而這個問題又分爲兩個： ①系統碎片化：咱們開發App時可能須要作到低版本兼容，好比，最低兼容至2.3版本；因爲各類Rom定製的盛行，國人都喜歡對原生系統作一些更改，這致使了在原生系統上可行，而在定製Rom上不可行的問題，好比相機調用~ ②屏幕碎片化：市面上各類各樣屏幕尺寸的手機，4.3寸，4.5寸，4.7寸，5.0寸，5.3寸...等等，除了手機外，還有Android平板，因此開發時咱們可能要處理這個屏幕適配的問題android

2.APP開發涉及架構

架構的簡單理解：

Application(應用程序層) 咱們通常說的應用層的開發就是在這個層次上進行的，固然包括了系統內置的一組應用程序，使用的是Java語言

Application Framework(應用程序框架層) 不管系統內置或者咱們本身編寫的App，都須要使用到這層，好比咱們想弄來電黑名單，自動掛斷電話，咱們就須要用到電話管理(TelephonyManager) 經過該層咱們就能夠很輕鬆的實現掛斷操做，而不須要關心底層實現

Libraries(庫) + Android Runtime(Android運行時) Android給咱們提供了一組C/C++庫，爲平臺的不一樣組件所使用，好比媒體框架；而Android Runtime則由Android核心庫集 + Dalvik虛擬機構成，Dalvik虛擬機是針對移動設備的虛擬機，它的特色:不須要很快的CPU計算速度和大量的內存空間;而每一個App都單獨地運行在單獨的Dalvik虛擬機內每一個app對於一條Dalvik進程）而他的簡單運行流程如：

Linux內核 這裏就是涉及底層驅動的東西了，一些系統服務，好比安全性，內存管理以及進程管理等

3.開發工具

Android Studio是比較吃配置的，若是電腦不怎麼好，建議仍是先使用Eclipse進行Android開發web

adb經常使用命令：面試

打包流程：算法

和Java不一樣，咱們的App運行在虛擬機上，而咱們的控制檯卻並不會顯示相關信息，只有安裝狀態而已，因此咱們會在Logcat上查看APP程序運行的日誌信息shell

----------------------------------------------------------------------------------------數據庫

什麼是簽名，有什麼用：

Android APP都須要咱們用一個證書對應用進行數字簽名，否則的話是沒法安裝到Android手機上的，平時咱們調試運行時到手機上時，是AS會自動用默認的密鑰和證書來進行簽名；可是咱們實際發佈編譯時，則不會自動簽名，這個時候咱們就須要進行手動簽名了！爲咱們的APK簽名有如下好處：編程

1.應用程序升級：若是你但願用戶無縫升級到新的版本，那麼你必須用同一個證書進行簽名。這是因爲只有以同一個證書籤名，系統纔會容許安裝升級的應用程序。若是你採用了不一樣的證書，那麼系統會要求你的應用程序採用不一樣的包名稱，在這種狀況下至關於安裝了一個全新的應用程序。若是想升級應用程序，簽名證書要相同，包名稱要相同！

2.應用程序模塊化： Android系統能夠容許同一個證書籤名的多個應用程序在一個進程裏運行，系統實際把他們做爲一個單個的應用程序，此時就能夠把咱們的應用程序以模塊的方式進行部署，而用戶能夠獨立的升級其中的一個模塊。

3.代碼或者數據共享： Android提供了基於簽名的權限機制，那麼一個應用程序就能夠爲另外一個以相同證書籤名的應用程序公開本身的功能。以同一個證書對多個應用程序進行簽名，利用基於簽名的權限檢查，你就能夠在應用程序間以安全的方式共享代碼和數據了。不一樣的應用程序之間，想共享數據，或者共享代碼，那麼要讓他們運行在同一個進程中，並且要讓他們用相同的證書籤名。 ————上述內容摘自:android 爲何須要簽名

Android Studio如何打包簽名：

好的，由於學習本課程的都是初學者，多渠道打包的內容之後再進行講解！本節只講最簡單的打包簽名對了，1中說的調試時默認生成的apk在：app/build/outputs/apk目錄下！和Eclipse並不相同，Eclipse是在bin目錄下生成的！緩存

好的，打開咱們的AS上的Hello World項目，點擊菜單：安全

①Build -> Generate Signed APK...

②彈出窗口，若是沒有key，就建立一個，有的話就選擇存在的Key

③沒有，咱們新建一個，可根據本身須要填寫相關項：

④好的，點擊OK後，能夠看到咱們密碼的信息，可能須要咱們填入密碼了，填寫下：

⑤點擊Next：

⑥點擊Finish稍等一下子會出現下述提示，說明應用已經打包簽名成功了：

⑦能夠看到打包後的APK已經安詳地躺在咱們的app目錄下了：

⑧到第七步就已經打包簽名完成了，若是你要驗證是否簽名，只須要輸入下述cmd指令

打包Android APK的方法還有不少，命令行，或者Gradle，ANT，MAVEN等等，方法有不少，本節講解最簡單的經過圖形化界面打包簽名的方式！好了，本節就到這裏，最簡單的打包簽名方法get了沒？

----------------------------------------------

4.線程的相關概念

1）相關概念：

程序：爲了完成特定任務，用某種語言編寫的一組指令集合(一組靜態代碼)

進程：運行中的程序，系統調度與資源分配的一個獨立單位，操做系統會爲每一個進程分配一段內存空間！程序的依次動態執行，經歷代碼的加載，執行，執行完畢的完整過程！

線程：比進程更小的執行單元，每一個進程可能有多條線程，線程須要放在一個進程中才能執行，線程由程序負責管理，而進程則由系統進行調度！

多線程的理解：並行執行多個條指令，將CPU時間片按照調度算法分配給各個線程，其實是分時執行的，只是這個切換的時間很短，用戶感受到"同時"而已！

Service與Thread線程的區別

其實他們二者並無太大的關係，不過有不少朋友常常把這兩個混淆了！ Thread是線程，程序執行的最小單元，分配CPU的基本單位！而Service則是Android提供一個容許長時間留駐後臺的一個組件，最多見的用法就是作輪詢操做！或者想在後臺作一些事情，好比後臺下載更新！記得別把這兩個概念混淆！

5.BroadcastReceiver

答：Broadcast直譯廣播，咱們舉個形象的例子來幫我理解下BroadcastReceiver，記得之前讀書的時候，每一個班級都會有一個掛在牆上的大喇叭，用來廣播一些通知，好比，開學要去搬書，廣播： "每一個班級找幾個同窗教務處拿書"，發出這個廣播後，全部同窗都會在同一時刻收到這條廣播通知，收到，但不是每一個同窗都會去搬書，通常去搬書的都是班裏的"大力士"，這羣"大力士"接到這條廣播後就會動身去把書搬回但是！
——好吧，上面這個就是一個廣播傳遞的一個很形象的例子：
大喇叭--> 發送廣播 --> 全部學生都能收到廣播 --> 大力士處理廣播
回到咱們的概念，其實BroadcastReceiver就是應用程序間的全局大喇叭，即通訊的一個手段，系統本身在不少時候都會發送廣播，好比電量低或者充足，剛啓動完，插入耳機，輸入法改變等，發生這些時間，系統都會發送廣播，這個叫系統廣播，每一個APP都會收到，若是你想讓你的應用在接收到這個廣播的時候作一些操做，好比：系統開機後，偷偷後臺跑服務~哈哈，這個時候你只須要爲你的應用註冊一個用於監視開機的BroadcastReceiver，當接收到開機廣播就作寫偷偷摸摸的勾當~ 固然咱們也能夠本身發廣播，好比：接到服務端推送信息，用戶在別處登陸，而後應該強制用戶下線回到登錄界面，並提示在別處登陸~固然，這些等下都會寫一個簡單的示例幫你們瞭解廣播給咱們帶來的好處~

讓咱們的APP接收系統廣播，接收以前，還須要爲咱們的APP註冊廣播接收器哦！而註冊的方法又分爲如下兩種：動態與靜態！

BroadcastReceiver的簡單使用就是那麼簡單，不過咱們這裏用到的都是全局廣播，也就是其餘應用也能收到咱們的廣播，這樣可能會引發一些安全性問題，不過沒事，下一節咱們來教你們如何用本地廣播

-----------------------------------------------------------------

6.SQLite是什麼？

SQLite數據庫，和其餘的SQL數據庫不一樣，咱們並不須要在手機上另外安裝一個數據庫軟件，Android系統已經集成了這個數據庫，咱們無需像使用其餘數據庫軟件(Oracle，MSSQL，MySql等)又要安裝，而後完成相關配置，又要改端口之類的！

爲何要用SQLite？SQLite有什麼特色？

　　①SQLite是一個輕量級的關係型數據庫，運算速度快，佔用資源少，很適合在移動設備上使用，不只支持標準SQL語法，還遵循ACID(數據庫事務)原則，無需帳號，使用起來很是方便！

SQLite支持五種數據類型:NULL,INTEGER,REAL(浮點數),TEXT(字符串文本)和BLOB(二進制對象) 雖然只有五種,可是對於varchar,char等其餘數據類型都是能夠保存的;由於SQLite有個最大的特色: 你能夠各類數據類型的數據保存到任何字段中而不用關心字段聲明的數據類型是什麼,

使用SQLite圖形化工具查看db文件筆者用的是SQLite Expert Professional

進入adb shell，接着鍵入下述指令

--------------------------------------------------

SQLite事務

簡單點說就是：寫在事務裏的全部數據庫操做都成功，事務提交，不然，事務回滾，就是回到前面的狀態——未執行數據庫操做的時候！另外，前面咱們也將了，在data/data/<包名>/database/目錄下除了有咱們建立的db文件外，還有一個xxx.db-journal這個文件就是用來讓數據庫支持事務而產生的臨時的日誌文件！

------------------------------------------------------

什麼是數據庫版本升級？怎麼升級法？

答：假如咱們開發了一款APP，裏面用到了數據庫，咱們假定這個數據庫版本爲v1.0，在這個版本，咱們建立了一個x.db的數據庫文件，咱們經過onCreate()方法建立了第一個table， t_user，裏面有兩個字段：_id,user_id；後面咱們想增長一個字段user_name，這個時候咱們就須要對數據庫表的結構進行修改了，而咱們能夠把更新數據庫的操做梵高onUpgrade() 方法中，咱們只須要在實例化自定義SQLiteOpenHelper的時候，修改版本號，好比把1改爲2 這樣，就會自動調用onUpgrade()的方法了！另外，對於每一個數據庫版本咱們都應該作好相應的記錄(文檔)，相似於下面這種:

數據庫版本	andoid對應版本	內容
v1.0	1	第一個版本，包含兩個字段...
v1.1	2	數據保留，新增user_name字段

一些疑問以及相關解決方案，測試時，要關注這些設計變動帶來的影響

①應用升級，數據庫文件是否會刪除？

答：不會！數據什麼的都在！

②若是我想刪除表中某個字段或者增長一個新的字段，原先的數據還在嗎？

答：在的！

③好比是這種，假如咱們已經升級到第三個版本了，咱們在第二個版本增長了一個表， 而後第三個版本也增長了一個表，加入用戶直接從第一個版本升級到第三個版本，這樣 沒通過第二個版本，就沒有增長的那個表，這可怎麼破？

答：很簡單，咱們能夠在onUpgrade()裏寫一個switch(),結構以下：
public void onUpgrade(SQLiteDatabase db, ConnectionSource connectionSource, int arg2, int arg3) { switch(arg2){ case 1: db.execSQL(第一個版本的建表語句); case 2: db.execSQL(第二個版本的建表語句); case 3: db.execSQL(第三個版本的建表語句); } }
細心的你可能發現這裏並無寫break，這就對了，這是爲了保證跨版本升級時，每次數據庫修改都能所有執行到！這樣能夠保證表結構都是最新的！另外不必定是建表語句，修改表結構也能夠哦！

④舊錶的設計太糟糕，不少字段要改，改動太多，想建一個新表，可是表名要同樣 並且之前的一些數據要保存到新表中！

答：呵呵，給你跪了，固然，也有解決辦法，下面說下思路：

1.將舊錶更名成臨時表: ALTER TABLE User RENAME TO _temp_User;

2.建立新表: CREATE TABLE User (u_id INTEGER PRIMARY KEY,u_name VARCHAR(20),u_age VARCHAR(4));

3.導入數據； INSERT INTO User SELECT u_id,u_name,"18" FROM _temp_User; //原表中沒有的要本身設個默認值

4.刪除臨時表； DROP TABLE_temp_User;

--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

7.APP網絡編程之Http協議　　

如今絕大部分的App都在使用http和https，須要客戶端主動向服務器發送請求，來獲取數據

Http 1.0 與 Http 1.1的區別

答：1.0協議，客戶端與web服務器創建鏈接後，只能得到一個web資源！而1.1協議，容許客戶端與web服務器創建鏈接後，在一個鏈接上獲取多個web資源！

而天誠百微APP使用的基於TCP協議的Socket通訊，來維持與服務器的長連接，該APP相似及時通訊工具（IM）

少部分會有本身的tcp長鏈接通道，更少部分的app搭配udp通道或者相似QUIC這種reliable UDP協議來提高體驗。無論是什麼協議，只要涉及客戶端和服務器的通訊，就必然要實現相似https安全握手的流程，部分或者所有，開發者老是在性能和安全性之間取捨。

若是自建長鏈接使用tcp，udp或者其餘網絡協議，也應該實現相似HTTPS的密鑰協商流程。

網絡分類：

　　1.以太網（Ethernet）:局域網（local area network，LAN）使用的就是以太網
2.英特網（Internet）：廣域網（wide area network，WAN）使用的就是Internet

Internet使用的通訊協議是TCP/IP協議，其是一個四層模型：

ARP協議：（Address Resolution Protocol）網絡地址解析協議，咱們知道的是IP也是配置在網卡上的，上面又提到網卡有固定的網卡號（MAC地址），實際上IP地址是經過軟件配置在指定網卡上的，經過向局域網發送ARP包可以返回具體IP配置所在的網卡的MAC地址。【注：獲取網卡MAC地址：#ifconfig，獲取本機IP/MAC地址對應數據：#arp -n】

ICMP協議：（Internet Control Message Protocol）因特網信息控制協議，其是一個錯誤檢測與報告的機制，用於確保網絡的鏈接狀態，經常使用的ping與traceroute命令便是使用的此協議，其也須要放到IP包裏進行傳輸。

Android與互聯網交互的三種方式

Http協議的底層工做流程：

答：咱們先要知道兩個名詞：

SYN(synchronous):TCP/IP創建鏈接時使用的握手信號

ACK(Acknowledgement):確認字符，確認發來的數據已經接受無誤

接着就到TCP/IP三次握手的概念：

客戶端發送syn包(syn = j)到服務器，進入SYN_SEND狀態，而後等待服務器確認

服務器收到syn包,確認客戶的syn(ack = j + 1),同時在本身也發送一個SYN包(syn=k)，即SYN + ACK包，服務器進入SYN_RECV狀態

客戶端收到SYN + ACK包，向服務器發送確認包ACK(ack = k +1),發送完畢後，客戶端與服務端進入ESTABLISHED狀態，完成三次握手，而後二者開始傳送數據

若是還不是很清晰，咱們再來看三次握手的示意圖：

APP緩存

如今不少門戶類信息網站，好比虎嗅，ifanr，鈦媒體等等的APP，簡單點說是信息閱讀類的APP，不少都是直接嵌套一個WebView用來顯示相關資訊的，這可能就涉及到了WebView的緩存了！

所謂的頁面緩存就是指：保存加載一個網頁時所需的HTML，JS，CSS等頁面相關的數據以及其餘資源，當沒網的時候或者網絡狀態較差的時候，加載本地保存好的相關數據！而實現這個緩存的方式有兩種，一種是後臺寫一個下載的Service，將文章相關的數據按本身的需求下載到數據庫或者保存到相應文件夾中，而後下次加載對應URL前先判斷是否存在本地緩存，若是存在優先加載本地緩存，不存在則執行聯網請求，同時緩存相關資源，典型的如舊版本的36Kr，在進去後會先離線文章，而後再顯示！

固然，本節要講解的不是這種本身寫邏輯的方式，而是經過WebView自己自帶的緩存功能來緩存頁面，這種方式使用起來很是簡單，咱們只需爲WebView設置開啓相關功能，以及設置數據庫的緩存路徑便可完成緩存！

--------------------------------------------------------------------------------------------------

Json是什麼？

答：JavaScript Object Natation, 一種輕量級的數據交換格式, 與XML同樣, 普遍被採用的客戶端和服務端交互的解決方案！具備良好的可讀和便於快速編寫的特性。

--------------------------------------------------------------------------------------------------------------------------------------------------------

8.APP網絡編程之Socket網絡基礎

故須要對數據傳給服務器，在服務器端作處理。

網絡協議有幾層？那麼IP協議在哪層？Socket是什麼鬼？分哪幾種？TCP和UDP協議又在哪層？有什麼區別...嗯，這...因此學習本節概念性的理論仍是頗有必要的！

七層模型每層叫什麼，大概拿來幹嗎，還有TCP三次握手和四次揮手

OSI七層網絡模型(從下往上)：

物理層(Physical)：設備之間的數據通訊提供傳輸媒體及互連設備，爲數據傳輸提供可靠的環境。能夠理解爲網絡傳輸的物理媒體部分，好比網卡，網線，集線器，中繼器，調制解調器等！在這一層，數據尚未被組織，僅做爲原始的位流或電氣電壓處理，這一層的單位是:bit比特

數據鏈路層(Datalink)：能夠理解爲數據通道，主要功能是如何在不可靠的物理線路上進行數據的可靠傳遞，改層做用包括：物理地址尋址，數據的成幀，流量控制，數據檢錯以及重發等！另外這個數據鏈路指的是：物理層要爲終端設備間的數據通訊提供傳輸媒體及其鏈接。媒體是長期的，鏈接是有生存期的。在鏈接生存期內，收發兩端能夠進行不等的一次或屢次數據通訊。每次通訊都要通過創建通訊聯絡和拆除通訊聯絡兩過程！這種創建起來的數據收發關係~ 該層的設備有：網卡，網橋，網路交換機，另外該層的單位爲：幀

網絡層(Network)：主要功能是將網絡地址翻譯成對應的物理地址，並決定如何將數據從發送方路由到接收方，所謂的路由與尋徑：一臺終端可能須要與多臺終端通訊，這樣就產生的了把任意兩臺終端設備數據連接起來的問題！簡單點說就是：創建網絡鏈接和爲上層提供服務！該層的設備有：路由！該層的單位爲：數據包，另外IP協議就在這一層！

傳輸層(Transport)：向上面的應用層提供通訊服務，面向通訊部分的最高層，同時也是用戶功能中的最低層。接收會話層數據，在必要時將數據進行分割，並將這些數據交給網絡層，而且保證這些數據段有效的到達對端！因此這層的單位是：數據段；而這層有兩個很重要的協議就是：TCP傳輸控制協議與UDP用戶數據報協議，這也是本章節核心講解的部分！

會話層(Session)：負責在網絡中的兩節點之間創建、維持和終止通訊。創建通訊連接，保持會話過程通訊連接的暢通，同步兩個節點之間的對話，決定通訊是否被中斷以及通訊中斷時決定從何處從新發送，即不一樣機器上的用戶之間會話的創建及管理！

表示層(Presentation)：對來自應用層的命令和數據進行解釋，對各類語法賦予相應的含義，並按照必定的格式傳送給會話層。其主要功能是"處理用戶信息的表示問題，如編碼、數據格式轉換和加密解密，壓縮解壓縮"等

應用層(Application)：OSI參考模型的最高層，爲用戶的應用程序提供網絡服務。它在其餘6層工做的基礎上，負責完成網絡中應用程序與網絡操做系統之間的聯繫，創建與結束使用者之間的聯繫，並完成網絡用戶提出的各類網絡服務及應用所需的監督、管理和服務等各類協議。此外，該層還負責協調各個應用程序間的工做。應用層爲用戶提供的服務和協議有：文件服務、目錄服務、文件傳輸服務（FTP）、遠程登陸服務（Telnet）、電子郵件服務（E-mail）、打印服務、安全服務、網絡管理服務、數據庫服務等。

好的上面咱們淺述了OSI七層網絡模型，下面總結下：

OSI是一個理想的模型，通常的網絡系統只涉及其中的幾層，在七層模型中，每一層都提供一個特殊的網絡功能，從網絡功能角度觀察：

下面4層（物理層、數據鏈路層、網絡層和傳輸層）主要提供數據傳輸和交換功能，即以節點到節點之間的通訊爲主

第4層做爲上下兩部分的橋樑，是整個網絡體系結構中最關鍵的部分；

上3層（會話層、表示層和應用層）則以提供用戶與應用程序之間的信息和數據處理功能爲主。

簡言之，下4層主要完成通訊子網的功能，上3層主要完成資源子網的功能。

2.TCP/IP四層模型

TCP/IP是一組協議的代名詞，它還包括許多協議，組成了TCP/IP協議簇。這4層分別爲：

應用層：應用程序間溝通的層，如簡單電子郵件傳輸（SMTP）、文件傳輸協議（FTP）、網絡遠程訪問協議（Telnet）等。

傳輸層：在此層中，它提供了節點間的數據傳送服務，如傳輸控制協議（TCP）、用戶數據報協議（UDP）等，TCP和UDP給數據包加入傳輸數據並把它傳輸到下一層中，這一層負責傳送數據，而且肯定數據已被送達並接收。

網絡互連層：負責提供基本的數據封包傳送功能，讓每一塊數據包都可以到達目的主機（但不檢查是否被正確接收），如網際協議（IP）。

主機到網絡層：對實際的網絡媒體的管理，定義如何使用實際網絡（如Ethernet、Serial Line等）來傳送數據。

3.TCP/UDP區別講解

接下來要講的是和咱們Socket開發相關的一些概念名詞了！

1）IP地址

2）端口

1. 用於區分不一樣的應用程序

2. 端口號的範圍爲0-65535，其中0-1023未系統的保留端口，咱們的程序儘量別使用這些端口！

3. IP地址和端口號組成了咱們的Socket，Socket是網絡運行程序間雙向通訊鏈路的終結點，是TCP和UDP的基礎！

4. 經常使用協議使用的端口：HTTP:80，FTP：21，TELNET：23

3）TCP協議與UDP協議的比較：

TCP協議流程詳解:

首先TCP/IP是一個協議簇，裏面包括不少協議的。UDP只是其中的一個。之因此命名爲TCP/IP協議，由於TCP,IP協議是兩個很重要的協議，就用他兩命名了。

下面咱們來說解TCP協議和UDP協議的區別：

TCP（Transmission Control Protocol，傳輸控制協議）是面向鏈接的協議，即在收發數據錢，都須要與對面創建可靠的連接，這也是面試常常會問到的TCP的三次握手以及TCP的四次揮手！ 三次握手：創建一個TCP鏈接時，須要客戶端和服務端總共發送3個包以確認鏈接的創建，在Socket編程中，這一過程由客戶端執行connect來觸發，具體流程圖以下：

第一次握手：Client將標誌位SYN置爲1，隨機產生一個值seq=J，並將該數據包發送給Server， Client進入SYN_SENT狀態，等待Server確認。

第二次握手：Server收到數據包後由標誌位SYN=1知道Client請求創建鏈接，Server將標誌位 SYN和ACK都置爲1，ack=J+1，隨機產生一個值seq=K，並將該數據包發送給Client以確認鏈接請求，Server進入SYN_RCVD狀態。

第三次握手：Client收到確認後，檢查ack是否爲J+1，ACK是否爲1，若是正確則將標誌位ACK 置爲1，ack=K+1，並將該數據包發送給Server，Server檢查ack是否爲K+1，ACK是否爲1，若是正確則鏈接創建成功，Client和Server進入ESTABLISHED狀態，完成三次握手，隨後Client與Server之間能夠開始傳輸數據了。

四次揮手：終止TCP鏈接，就是指斷開一個TCP鏈接時，須要客戶端和服務端總共發送4個包以確認鏈接的斷開。在Socket編程中，這一過程由客戶端或服務端任一方執行close來觸發，具體流程圖以下：

第一次揮手：Client發送一個FIN，用來關閉Client到Server的數據傳送，Client進入 FIN_WAIT_1狀態

第二次揮手：Server收到FIN後，發送一個ACK給Client，確認序號爲收到序號+1（與SYN相同，一個FIN佔用一個序號），Server進入CLOSE_WAIT狀態。

第三次揮手：Server發送一個FIN，用來關閉Server到Client的數據傳送，Server進入LAST_ACK 狀態。

第四次揮手：Client收到FIN後，Client進入TIME_WAIT狀態，接着發送一個ACK給Server，確認序號爲收到序號+1，Server進入CLOSED狀態，完成四次揮手。另外也多是同事發起主動關閉的狀況：

另外還可能有一個常見的問題就是：爲何創建鏈接是三次握手，而關閉鏈接倒是四次揮手呢？答：由於服務端在LISTEN狀態下，收到創建鏈接請求的SYN報文後，把ACK和SYN放在一個報文裏發送給客戶端。而關閉鏈接時，當收到對方的FIN報文時，僅僅表示對方再也不發送數據了可是還能接收數據，己方也未必所有數據都發送給對方了，因此己方能夠當即close，也能夠發送一些數據給對方後，再發送FIN報文給對方來表示贊成如今關閉鏈接，所以，己方ACK和FIN通常都會分開發送。

UDP協議詳解：

UDP(User Datagram Protocol)用戶數據報協議，非鏈接的協議，傳輸數據以前源端和終端不創建鏈接，當它想傳送時就簡單地去抓取來自應用程序的數據，並儘量快地把它扔到網絡上。在發送端，UDP傳送數據的速度僅僅是受應用程序生成數據的速度、計算機的能力和傳輸帶寬的限制；在接收端，UDP把每一個消息段放在隊列中，應用程序每次從隊列中讀一個消息段。相比TCP就是無需創建連接，結構簡單，沒法保證正確性，容易丟包

——上述內容部分摘自：

TCP/IP三次握手與四次揮手

TCP和UDP的區別（轉）