目录
文章未完成
一、OSI模型
1、OSI模型基础知识速览
OSI模型
2、五层协议的体系结构
五层协议
二、Android架构图
Android的系统架构采用了分层架构的思想，如图1所示。从上层到底层共包括四层，分别是应用程序程序层、应用框架层、系统库和Android运行时、Linux内核层。
安卓架构图.png
1、应用程序层
该层提供一些核心应用程序包，例如电子邮件、短信、日历、地图、浏览器和联系人管理等。同时，开发者可以利用Java语言设计和编写属于自己的应用程序，而这些程序与那些核心应用程序彼此平等、友好共处。
2、应用程序框架层
这一层是编写Google发布的核心应用时所使用的Android应用开发的基础API框架，开发人员大部分情况是在和她打交道，这样便简化了程序开发的结构设计，但是必须要遵守其框架的开发原则。应用程序框架层包括活动管理器、窗口管理器、内容提供者、视图系统、包管理器、电话管理器、资源管理器、位置管理器、通知管理器和XMPP服务十个部分。
3、 系统运行库（C/C++库以及Android运行库）层
当使用Android应用框架时，Android系统会通过一些C/C++库来支持我们使用的各个组件，使其更好的为我们服务。系统库包括九个子系统，分别是图层管理、媒体库、SQLite、OpenGLEState、FreeType、WebKit、SGL、SSL和libc。
Android运行时包括核心库和Dalvik虚拟机，前者既兼容了大多数Java语言所需要调用的功能函数，又包括了Android的核心库，比如android.os、android.net、android.media等等。后者是一种基于寄存器的java虚拟机，Dalvik虚拟机主要是完成对生命周期的管理、堆栈的管理、线程的管理、安全和异常的管理以及垃圾回收等重要功能。
关于Dalvik VM (DVM) 与Java VM (JVM)的区别，请点击查看。
4、Linux内核层
Android核心系统服务依赖于Linux2.6内核，如安全性、内存管理、进程管理、网络协议栈和驱动模型。Linux内核也是作为硬件与软件栈的抽象层。驱动：显示驱动、摄像头驱动、键盘驱动、WiFi驱动、Audio驱动、flash内存驱动、Binder（IPC）驱动、电源管理等。
三、TCP协议
1、三次握手（建立连接）
-
TCP(Transmission Control Protocol) 传输控制协议。TCP是主机对主机层的传输控制协议，提供可靠的连接服务，采用三次握手确认建立一个连接:
-
TCP报文段首部格式：
TCP报文段
（1）序号：Seq序号，占32位，用来标识从TCP源端向目的端发送的字节流，发起方发送数据时对此进行标记。
（2）确认号ack：期待收到对方下一个报文段的第一个数据字节的序号
（3）标志位：共6个，即URG、ACK、PSH、RST、SYN、FIN等，具体含义如下：
（A）URG：紧急指针（urgent pointer）有效。
（B）确认ACK：确认序号有效。占1位，仅当ACK=1时，确认号字段才有效。ACK=0时，确认号无效。
（C）PSH：接收方应该尽快将这个报文交给应用层。
（D）RST：重置连接。
（E）同步SYN：发起一个新连接。连接建立时用于同步序号。当SYN=1，ACK=0时表示：这是一个连接请求报文段。
** （F）FIN：释放一个连接。**
若同意连接，则在响应报文段中使得SYN=1，ACK=1。
因此，SYN=1表示这是一个连接请求，或连接接受报文。
终止FIN：用来释放一个连接。
FIN=1表示：此报文段的发送方的数据已经发送完毕，并要求释放运输连接
-
过程
-
第一次握手：请求连接时，客户端发送SYN=1，ACK=0(连接请求报文段)、自己的seq序号x到服务器，并进入SYN_SEND状态，等待服务器确认；
-
第二次握手：服务器收到请求，发送SYN=1，ACK=1(连接响应报文段)、自己的seq序号y、确认号ack=x+1，到客户端表示连接接受，此时服务器进入SYN_RECV状态；
-
第三次握手：客户端收到后检查ack是否正确，即第一次发送的seq(x)+1,以及确认ACK是否为1，若正确再次回应服务器端一个确认ACK=1、确认号ack=y+1和seq(x)+1确认数据段。客户端和服务器进入ESTABLISHED状态
-
完成三次握手，主机A与主机B开始传送数据。
三次握手
-
-
重点分析
还要再发送一次确认是为了，防止已失效的连接请求报文段突然又传到了B，因而产生错误。已失效的报文段：正常情况下：A发出连接请求，但因为丢失了，故而不能收到B的确认。于是A重新发出请求，然后收到确认，建立连接，数据传输完毕后，释放连接，A发了2个，一个丢掉，一个到达，没有“已失效的报文段”。
但是，某种情况下，A的第一个在某个节点滞留了，延误到达，本来这是一个早已失效的报文段，但是在A发送第二个，并且得到B的回应，建立了连接以后，这个报文段竟然到达了，于是B就认为，A又发送了一个新的请求，于是发送确认报文段，同意建立连接，假若没有三次的握手，那么这个连接就建立起来了（有一个请求和一个回应），此时，A收到B的确认，但A知道自己并没有发送建立连接的请求，因为不会理睬B的这个确认，于是呢，A也不会发送任何数据，而B呢却以为新的连接建立了起来，一直等待A发送数据给自己，此时B的资源就被白白浪费了。但是采用三次握手的话，A就不发送确认，那么B由于收不到确认，也就知道并没有要求建立连接。
2、四次握手（释放连接）
-
终止FIN：用来释放一个连接。FIN=1表示：此报文段的发送方的数据已经发送完毕，并要求释放运输连接
-
步骤
（1）第一次挥手：客户端A发送一个FIN、自己的seq序号u用来关闭客户A到服务器B的数据传送。Client进入FIN_WAIT_1状态。
（2）第二次挥手：服务器B收到这个FIN，它发回一个ACK=1、ack=u+1、自己的序号seq=v，Server进入CLOSE_WAIT状态。
（3）第三次挥手：Server发送一个FIN、自己的序号seq=w，用来关闭Server到Client的数据传送，Server进入LAST_ACK状态。
（4）第四次挥手：Client收到FIN后，Client进入TIME_WAIT状态，接着发给Server一个ACK=1、ack=w+1、自己的序号seq=u+1，Server进入CLOSED状态，完成四次挥手。
四次握手
3、总结
-
为什么建立连接协议是三次握手，而关闭连接却是四次握手呢？
这是因为服务端的LISTEN状态下的SOCKET当收到SYN报文的建连请求后，它可以把ACK和SYN（ACK起应答作用，而SYN起同步作用）放在一个报文里来发送。但关闭连接时，ACK却没有和FIN一起发送，原因是因为tcp是全双工模式，当收到对方的FIN报文通知时，它仅仅表示对方没有数据发送给你了；但未必你所有的数据都全部发送给对方了，所以你可以未必会马上会关闭SOCKET,也即你可能还需要发送一些数据给对方之后，再发送FIN报文给对方来表示你同意现在可以关闭连接了，所以它这里的ACK报文和FIN报文多数情况下都是分开发送的. -
为什么TIME_WAIT状态还需要等2MSL后才能返回到CLOSED状态？
①、为了保证A发送的最后一个ACK报文段能够到达B。即最后这个确认报文段很有可能丢失，那么B会超时重传，然后A再一次确认，同时启动2MSL计时器，如此下去。如果没有等待时间，发送完确认报文段就立即释放连接的话，B就无法重传了（连接已被释放，任何数据都不能出传了），因而也就收不到确认，就无法按照步骤进入CLOSE状态，即必须收到确认才能close。②、防止“已失效的连接请求报文段”出现在连接中。经过2MSL，那些在这个连接持续的时间内，产生的所有报文段就可以都从网络中消失。即在这个连接释放的过程中会有一些无效的报文段滞留在楼阁结点，但是呢，经过2MSL这些无效报文段就肯定可以发送到目的地，不会滞留在网络中。这样的话，在下一个连接中就不会出现上一个连接遗留下来的请求报文段了。
可以看出：B结束TCP连接的时间比A早一点，因为B收到确认就断开连接了，而A还得等待2MSL.
四、JVM内存结构和内存管理
整理作者：汪博
少壮不努力，老大徒悲伤。
本文为Android学习规划打造，如有不好的地方请多多指教。
网友评论