Merge pull request LRH1993#25 from Notzuonotdied/master

调整了多出Markdown编辑细节，修改了两处表述。

Author: LRH1993

android/advance/binder.md

@@ -4,7 +4,7 @@
 
 提到MVP，就必须要先介绍一下它的前辈MVC，因为MVP正是基于MVC的基础发展而来的。两个之间的关系也是源远流长。
 
-**MVC，全称Model-View-Controller，即模型-视图-控制器。**具体如下：
+**MVC，全称Model-View-Controller，即模型-视图-控制器。** 具体如下：
 
 **View：对应于布局文件**
 

android/advance/mvp.md

@@ -6,13 +6,10 @@ Serializable的作用是**为了保存对象的属性到本地文件、数据库
 
 从上面的设计上我们就可以看出优劣了。
 
- 
 
 **2、效率及选择**
 
-Parcelable的性能比Serializable好，在内存开销方面较小，所以**在内存间数据传输时推荐使用Parcelable**，如activity间传输数据，而Serializable可将数据持久化方便保存，所以**在需要保存或网络传输数据时选择Serializable**，因为android不同版本Parcelable可能不同，所以不推荐使用Parcelable进行数据持久化
-
-
+Parcelable的性能比Serializable好，在内存开销方面较小，所以**在内存间数据传输时推荐使用Parcelable**，如activity间传输数据，而Serializable可将数据持久化方便保存，所以**在需要保存或网络传输数据时选择Serializable**，因为android不同版本Parcelable可能不同，所以不推荐使用Parcelable进行数据持久化。
 
 **3、编程实现**
 
@@ -72,4 +69,4 @@ in.readStringList(list);
 
 **4、高级功能上**
 
-Serializable序列化不保存静态变量，可以使用Transient关键字对部分字段不进行序列化，也可以覆盖writeObject、readObject方法以实现序列化过程自定义
+Serializable序列化不保存静态变量，可以使用Transient关键字对部分字段不进行序列化，也可以覆盖writeObject、readObject方法以实现序列化过程自定义。

android/advance/serializable.md

@@ -37,7 +37,8 @@ IGMP是Internet组管理协议。它用来把一个UDP数据报多播到多个
 
 TCP为两台主机提供高可靠性的数据通信。它所做的工作包括把应用程序交给它的数据分成合适的小块交给下面的网络层，确认接收到的分组，设置发送最后确认分组的超时时钟等。由于运输层提供了高可靠性的端到端的通信，因此应用层可以忽略所有这些细节。为了提供可靠的服务，TCP采用了超时重传、发送和接收端到端的确认分组等机制。
 
-UDP则为应用层提供一种非常简单的服务。它只是把称作数据报的分组从一台主机发送到另一台主机，但并不保证该数据报能到达另一端。一个数据报是指从发送方传输到接收方的一个信息单元（例如，发送方指定的一定字节数的信息）。UDP协议任何必需的可靠性必须由应用层来提供。  
+UDP则为应用层提供一种非常简单的服务。它只是把称作数据报的分组从一台主机发送到另一台主机，但并不保证该数据报能到达另一端。一个数据报是指从发送方传输到接收方的一个信息单元（例如，发送方指定的一定字节数的信息）。UDP协议任何必需的可靠性必须由应用层来提供。
+
 \(4\). 应用层
 
 应用层决定了向用户提供应用服务时通信的活动。TCP/IP 协议族内预存了各类通用的应用服务。包括 HTTP，FTP（File Transfer Protocol，文件传输协议），DNS（Domain Name System，域名系统）服务。  
@@ -77,20 +78,21 @@ TCP是面向连接的，无论哪一方向另一方发送数据之前，都必
 
 ![](http://upload-images.jianshu.io/upload_images/3985563-f2fe3775bd2678c2.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
 
-  
-
-
-第一次握手：建立连接。客户端发送连接请求报文段，将SYN位置为1，Sequence Number为x；然后，客户端进入SYN\_SEND状态，等待服务器的确认；
-
-第二次握手：服务器收到SYN报文段。服务器收到客户端的SYN报文段，需要对这个SYN报文段进行确认，设置Acknowledgment Number为x+1\(Sequence Number+1\)；同时，自己自己还要发送SYN请求信息，将SYN位置为1，Sequence Number为y；服务器端将上述所有信息放到一个报文段（即SYN+ACK报文段）中，一并发送给客户端，此时服务器进入SYN\_RECV状态；
-
-第三次握手：客户端收到服务器的SYN+ACK报文段。然后将Acknowledgment Number设置为y+1，向服务器发送ACK报文段，这个报文段发送完毕以后，客户端和服务器端都进入ESTABLISHED状态，完成TCP三次握手。
+| 回合 | 说明 |
+| ---- | ------------------ |
+| 第一次握手 | 建立连接。客户端发送连接请求报文段，将SYN位置为1，Sequence Number为x；然后，客户端进入SYN\_SEND状态，等待服务器的确认； |
+| 第二次握手 | 服务器收到SYN报文段。服务器收到客户端的SYN报文段，需要对这个SYN报文段进行确认，设置Acknowledgment Number为x + 1\(Sequence Number + 1\)；同时，自己自己还要发送SYN请求信息，将SYN位置为1，Sequence Number为y；服务器端将上述所有信息放到一个报文段（即SYN + ACK报文段）中，一并发送给客户端，此时服务器进入SYN\_RECV状态； |
+| 第三次握手 | 客户端收到服务器的SYN + ACK报文段。然后将Acknowledgment Number设置为y + 1，向服务器发送ACK报文段，这个报文段发送完毕以后，客户端和服务器端都进入ESTABLISHED状态，完成TCP三次握手。 |
 
 ##### 为什么要三次握手
 
 为了防止已失效的连接请求报文段突然又传送到了服务端，因而产生错误。
 
-**具体例子：**“已失效的连接请求报文段”的产生在这样一种情况下：client发出的第一个连接请求报文段并没有丢失，而是在某个网络结点长时间的滞留了，以致延误到连接释放以后的某个时间才到达server。本来这是一个早已失效的报文段。但server收到此失效的连接请求报文段后，就误认为是client再次发出的一个新的连接请求。于是就向client发出确认报文段，同意建立连接。假设不采用“三次握手”，那么只要server发出确认，新的连接就建立了。由于现在client并没有发出建立连接的请求，因此不会理睬server的确认，也不会向server发送数据。但server却以为新的运输连接已经建立，并一直等待client发来数据。这样，server的很多资源就白白浪费掉了。采用“三次握手”的办法可以防止上述现象发生。例如刚才那种情况，client不会向server的确认发出确认。server由于收不到确认，就知道client并没有要求建立连接。”
+**具体例子：** ——“已失效的连接请求报文段”的产生在这样一种情况下：
+
+client发出的第一个连接请求报文段并没有丢失，而是在某个网络结点长时间的滞留了，以致延误到连接释放以后的某个时间才到达server。本来这是一个早已失效的报文段。但server收到此失效的连接请求报文段后，就误认为是client再次发出的一个新的连接请求。于是就向client发出确认报文段，同意建立连接。假设不采用“三次握手”，那么只要server发出确认，新的连接就建立了。由于现在client并没有发出建立连接的请求，因此不会理睬server的确认，也不会向server发送数据。但server却以为新的运输连接已经建立，并一直等待client发来数据。这样，server的很多资源就白白浪费掉了。采用“三次握手”的办法可以防止上述现象发生。
+
+例如刚才那种情况，client不会向server的确认发出确认。server由于收不到确认，就知道client并没有要求建立连接。”
 
 ### 四、HTTP协议
 
@@ -100,20 +102,19 @@ TCP是面向连接的，无论哪一方向另一方发送数据之前，都必
 
 **四个基于：**
 
-**请求与响应：**客户端发送请求，服务器端响应数据
+**请求与响应：** 客户端发送请求，服务器端响应数据
 
-**无状态的：**协议对于事务处理没有记忆能力，客户端第一次与服务器建立连接发送请求时需要进行一系列的安全认证匹配等，因此增加页面等待时间，当客户端向服务器端发送请求，服务器端响应完毕后，两者断开连接，也不保存连接状态，一刀两断！恩断义绝！从此路人！下一次客户端向同样的服务器发送请求时，由于他们之前已经遗忘了彼此，所以需要重新建立连接。
+**无状态的：** 协议对于事务处理没有记忆能力，客户端第一次与服务器建立连接发送请求时需要进行一系列的安全认证匹配等，因此增加页面等待时间，当客户端向服务器端发送请求，服务器端响应完毕后，两者断开连接，也不保存连接状态，一刀两断！恩断义绝！从此路人！下一次客户端向同样的服务器发送请求时，由于他们之前已经遗忘了彼此，所以需要重新建立连接。
 
-**应用层：**Http是属于应用层的协议，配合TCP/IP使用。
+**应用层：** Http是属于应用层的协议，配合TCP/IP使用。
 
-**TCP/IP：**Http使用TCP作为它的支撑运输协议。HTTP客户机发起一个与服务器的TCP连接，一旦连接建立，浏览器（客户机）和服务器进程就可以通过套接字接口访问TCP。
+**TCP/IP：** Http使用TCP作为它的支撑运输协议。HTTP客户机发起一个与服务器的TCP连接，一旦连接建立，浏览器（客户机）和服务器进程就可以通过套接字接口访问TCP。
 
 **针对无状态的一些解决策略：**
 
 有时需要对用户之前的HTTP通信状态进行保存，比如执行一次登陆操作，在30分钟内所有的请求都不需要再次登陆。于是引入了Cookie技术。
 
-HTTP/1.1想出了持久连接（HTTP keep-alive）方法。其特点是，只要任意一端没有明确提出断开连接，则保持TCP连接状态，在请求首部字段中的Connection: keep-alive即为表明使用了持久连接。  
-等等还有很多。。。。。。
+HTTP/1.1想出了持久连接（HTTP keep-alive）方法。其特点是，只要任意一端没有明确提出断开连接，则保持TCP连接状态，在请求首部字段中的Connection: keep-alive即为表明使用了持久连接。等等还有很多……
 
 下面开始讲解重头戏：HTTP请求报文，响应报文，对应于上述步骤的2，3，4，5，6。
 
@@ -141,7 +142,7 @@ HTTP/1.1 定义的请求方法有8种：GET、POST、PUT、DELETE、PATCH、HEAD
 
 **请求地址**
 
-URL:统一资源定位符，是一种自愿位置的抽象唯一识别方法。
+URL：统一资源定位符，是一种自愿位置的抽象唯一识别方法。
 
 组成：<协议>：//<主机>：<端口>/<路径>
 
@@ -214,12 +215,13 @@ HTTP响应报文主要由状态行、响应头部、空行以及响应数据组
 
 **状态码**
 
-状态代码为3位数字。  
-1xx：指示信息--表示请求已接收，继续处理。  
-2xx：成功--表示请求已被成功接收、理解、接受。  
-3xx：重定向--要完成请求必须进行更进一步的操作。  
-4xx：客户端错误--请求有语法错误或请求无法实现。  
-5xx：服务器端错误--服务器未能实现合法的请求。
+状态代码为3位数字。
+
+ - 1xx：指示信息——表示请求已接收，继续处理。
+ - 2xx：成功——表示请求已被成功接收、理解、接受。
+ - 3xx：重定向——要完成请求必须进行更进一步的操作。
+ - 4xx：客户端错误——请求有语法错误或请求无法实现。
+ - 5xx：服务器端错误——服务器未能实现合法的请求。
 
 下面列举几个常见的：
 
@@ -274,22 +276,18 @@ HTTP响应报文主要由状态行、响应头部、空行以及响应数据组
 
 ### 七、TCP四次挥手
 
-当客户端和服务器通过三次握手建立了TCP连接以后，当数据传送完毕，肯定是要断开TCP连接的啊。那对于TCP的断开连接，这里就有了神秘的“四次分手”。  
+当客户端和服务器通过三次握手建立了TCP连接以后，当数据传送完毕，肯定是要断开TCP连接的啊。那对于TCP的断开连接，这里就有了神秘的“四次分手”。
 
 
 ![](http://upload-images.jianshu.io/upload_images/3985563-c1c59148f8b26c43.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
 
 
-
-
-  
-第一次分手：主机1（可以使客户端，也可以是服务器端），设置Sequence Number，向主机2发送一个FIN报文段；此时，主机1进入FIN\_WAIT\_1状态；这表示主机1没有数据要发送给主机2了；
-
-第二次分手：主机2收到了主机1发送的FIN报文段，向主机1回一个ACK报文段，Acknowledgment Number为Sequence Number加1；主机1进入FIN\_WAIT\_2状态；主机2告诉主机1，我“同意”你的关闭请求；
-
-第三次分手：主机2向主机1发送FIN报文段，请求关闭连接，同时主机2进入LAST\_ACK状态；
-
-第四次分手：主机1收到主机2发送的FIN报文段，向主机2发送ACK报文段，然后主机1进入TIME\_WAIT状态；主机2收到主机1的ACK报文段以后，就关闭连接；此时，主机1等待2MSL后依然没有收到回复，则证明Server端已正常关闭，那好，主机1也可以关闭连接了。
+| 回合 | 说明 |
+| ------ | ------------------ |
+| 第一次分手 | 主机1（可以使客户端，也可以是服务器端），设置Sequence Number，向主机2发送一个FIN报文段；此时，主机1进入FIN\_WAIT\_1状态；这表示主机1没有数据要发送给主机2了； |
+| 第二次分手 | 主机2收到了主机1发送的FIN报文段，向主机1回一个ACK报文段，Acknowledgment Number为Sequence Number加1；主机1进入FIN\_WAIT\_2状态；主机2告诉主机1，我“同意”你的关闭请求； |
+| 第三次分手 | 主机2向主机1发送FIN报文段，请求关闭连接，同时主机2进入LAST\_ACK状态； |
+| 第四次分手 | 主机1收到主机2发送的FIN报文段，向主机2发送ACK报文段，然后主机1进入TIME\_WAIT状态；主机2收到主机1的ACK报文段以后，就关闭连接；此时，主机1等待2MSL后依然没有收到回复，则证明Server端已正常关闭，那好，主机1也可以关闭连接了。 |
 
 ##### 为什么要四次分手