目录
1 以太网协议
Ethernet 以太网协议应用于OSI模型的数据链路层，是一种计算机局域网技术，用于解决两台相连主机之间的通信问题。
2 IP协议
P协议应用于OSI模型的网络层。
3 UDP协议
UDP协议应用于OSI模型的传输层，是一种面向无连接，不可靠的，基于数据报的传输层通信协议。其首部开销小，传输数据报文时很是高效。
无需建立连接：发送端发送数据前不需要像TCP那样建立连接。具体来说就是，如果使用UDP协议进行通信，应用层会将数据传到传输层，传输层给数据加上UDP的头部标识后，直接传递到网络层，再经链路层、物理层通过网络传给接受方。接受端网络层将数据传递给传输层，UDP 只去除 IP 报文头就传递给应用层，不会任何拼接操作，有单播、多播、广播的功能。
面向报文：发送方的UDP对应用程序交下来的报文，在添加首部后就向下交付IP层。UDP对应用层交下来的报文，既不合并，也不拆分，而是保留这些报文的边界。因此，应用程序必须选择合适大小的报文。
不可靠性：首先不可靠性体现在无连接上，通信都不需要建立连接，想发就发，这样的情况肯定不可靠。 并且收到什么数据就传递什么数据，并且也不会备份数据，发送数据也不会关心对方是否已经正确接收到数据了。再者网络环境时好时坏，但是 UDP 因为没有拥塞控制，一直会以恒定的速度发送数据。即使网络条件不好，也不会对发送速率进行调整。这样实现的弊端就是在网络条件不好的情况下可能会导致丢包，但是优点也很明显，在某些实时性要求高的场景（比如电话会议）就需要使用 UDP 而不是 TCP。
4 TCP协议
TCP协议同样应用于OSI模型的传输。
通过 UDP 协议，A 无忧无虑地同 B 进行着通信，一直没发生什么问题。
但是由于网络的不可靠，数据包可能在半路丢失，而 A 和 B 却无法察觉。
4.1 丢包问题
第一个，A 怎么知道包丢了？
答案：让 B 告诉 A
第二个，丢了的包怎么办？
答案：重传
于是可以设计如下方案，A 每发一个包，都必须收到来自 B 的确认（ACK），再发下一个，否则在一定时间内没有收到确认，就重传这个包。
只要按照这个协议来，虽然 A 无法保证 B 一定能收到包，但 A 能够确认 B 是否收到了包，收不到就重试，尽最大努力让这个通信过程变得可靠，于是现在的通信过程有了一个新的特征，可靠交付。
停止等待ACK虽然能解决问题，但是效率太低了，A 原本可以在发完第一个数据包之后立刻开始发第二个数据包，但由于停止等待，A 必须等数据包到达了 B ，且 B 的 ACK 包又回到了 A，才可以继续发第二个数据包，这效率慢得可不是一点两点。于是对这个过程再次改进，采用流水线的方式，不再傻傻地等。
但是网路是复杂的、不可靠的。有的时候 A 发出去的数据包，分别走了不同的路由到达 B，可能无法保证和发送数据包时一样的顺序。这样在流水线中就会有多个数据包和ACK包在乱序流动，他们之间对应关系就乱掉了。
为了应对以上情况，我们可以在 A 发送的数据包中增加一个序号（seq），同时 B 要在 ACK 包上增加一个确认号（ack），这样不但解决了停止等待的效率问题，也通过这样标序号的方式解决了顺序问题。而 B 这个确认号意味深长：比如 B 发了一个确认号为 ack = 3，它不仅仅表示 A 发送的序号为 2 的包收到了，还表示 2 之前的数据包都收到了。这种方式叫累计确认或累计应答。（注意，在TCP协议中，实际上 ack 的号是收到的最后一个数据包的序号 seq + 1，也就是告诉对方下一个应该发的序号是多少。）
4.2 流量问题
有的时候，A 发送数据包的速度太快，而 B 的接收能力不够，但 B 却没有告知 A 这个情况。
因此在TCP协议中，有一个严谨的规范，B 在每次发送数据包给 A 时，会顺带传过来一个值，叫窗口大小（win)，这个值就表示 B 的接收能力。这样A 根据 B 的接收能力，相应控制自己的发送速率。同理，每次 A 给 B 发包时也带上自己的窗口大小，表示 A 的接收能力。
4.3 拥塞问题
但有的时候，不是 B 的接受能力不够，而是网络不太好，造成了网络拥塞。
拥塞控制与流量控制有些像，但流量控制是受 B 的接收能力影响，而拥塞控制是受网络环境的影响。
拥塞控制的解决办法依然是通过设置一定的窗口大小，只不过，流量控制的窗口大小是 B 直接告诉 A 的，而拥塞控制的窗口大小只能 A 单方面通过试探，不断感知网络环境的好坏，进而确定自己的拥塞窗口的大小。
拥塞窗口大小的计算有很多复杂的算法，假如拥塞窗口的大小为 cwnd，流量控制的滑动窗口的大小为 rwnd，那么窗口的右边界受这两个值共同的影响，需要取它俩的最小值。窗口大小 = min(cwnd, rwnd)。含义很容易理解，当 B 的接受能力比较差时，即使网络非常通畅，A 也需要根据 B 的接收能力限制自己的发送窗口。当网络环境比较差时，即使 B 有很强的接收能力，A 也要根据网络的拥塞情况来限制自己的发送窗口。
4.4 连接问题
有的时候，B 主机的相应进程还没有准备好或是挂掉了，A 就开始发送数据包，导致了浪费。
对于这个问题，就就是TCP的三次握手！
- A：我准备好了(SYN)
- B：我知道了(ACK)，我也准备好了(SYN)
- A：我知道了(ACK)
A 与 B 各自在内存中维护着自己的状态变量，三次握手之后，双方的状态都变成了连接已建立（ESTABLISHED）。这个双方建立连接的过程，就叫面向连接。
但凡事有始就有终，有了建立连接的过程，就要考虑释放连接的过程，这就是四次挥手！
- A：再见，我要关闭了(FIN)
- 我知道了(ACK)（给 B 一段时间把自己的事情处理完…）
- 再见，我要关闭了(FIN)
- 我知道了(ACK)
4.5 总结
以上描述的，就是 TCP 协议的核心思想，上面过程中需要传输的信息，就体现在 TCP 协议的首部，下图就是最常见的 TCP 协议头解读图。
TCP 是面向连接的、可靠的、基于字节流的传输层通信协议。
面向连接与可靠这两个词通过上面的描述很容易理解，那什么叫做基于字节流呢？
很简单，TCP 在建立连接时，需要告诉对方 MSS（最大报文段大小）。也就是说，如果要发送的数据很大，在 TCP 层是需要按照 MSS 来切割成一个个的 TCP 报文段 的。切割的时候不管原来的数据表示什么意思，需要在哪里断句啥的，只会把数据当成一串毫无意义的字节，在需要切割的地方咔嚓一刀，然后标上序号，最后接收方再根据这个序号拼成最终想要的完整数据就行了。在 TCP 传输中，这些TCP报文段就会被当做一个个的字节，也就是基于字节流的含义了。
5 IPCP协议
IPCP协议应用于OSI模型的应用层。
For IP Command Protocol communication, the figure below shows the relation between the PDU header on the application layer, the UDP/TCP handling on the transport layer and also the IP handling on the network layer.
The PDU header shall be defined according to the figure below. The payload field is variable and optional.
5.1 IPCP Header
IP Application Header Size: 16 bytes (128 bits) in total.
| ServiceID | 16 bit | The 16 bit service identifier (ServiceID) is used to identify a specific service that a server provides. Examples of services provided by the subsystems are Telematics, Phone, Connectivity etc. |
| OperationID | 16 bit | The 16 bit OperationID shall be used to identify which service operation that shall be used. The OperationID must be unique for each operation that is supported in the vehicle. |
| Length | 32 bit | The Length-field consists of 32 bits containing the length in Byte of the payload. The length shall also include the following parameters into the length calculation; the SenderHandleID , ProtocolVersion ,OperationType , DataType , option flags and Reserved , which means that the minimum length shall always be 8 bytes. The beginning of the length calculation is at the beginning of the SenderHandleID , offset 64. |
| SenderHandleID | 32 bit | SenderHandleID is a locally (in the application) unique “message session” identifier used to tell apart multiple replies from the same source It allows a client do differentiate multiple calls to the same operation. |
| ProtocolVersion | 8 bit | Protocol version is an identifier defining the version of the IP Command protocol which is used. |
| OperationType | 8 bit | The OperationType identifier is used to distinguish between different types of messages, request, notifications, response etc. Each operation type will be explained further in detail in the following subchapters in conjunction with Message Format Sequences. |
| DataType | 8 bit | The DataType is 8 bits long and defines how the sender/receiver shall handle the payload (data field) of the message. |
| proc | 1 bit | Process-flag, defines an alternative handling procedure by a server. |
| Reserved | 7 bit | 7 bit area, reserved for future use, set to 0x00. |
| Payload | Variable size | Actual intended message. |
5.2 SenderHandleID
| ServiceID | 8 bit | ServiceID shall consist of the last byte of the 16 bit ServiceID. |
| OperationID | 8 bit | OperationID shall consist of the last byte of the 16 bit OperationID. |
| OperationType | 8 bit | OpType shall use the same value as the OpType. |
| Seq Nr | 8 bit | SeqNr is a sequence number shall be locally unique in the client application for each message to be sent. |
5.3 DataType
| Number | Friendly Name | Description |
|---|---|---|
| 0x00 | Encoded message | Indicates that the payload (data) is encoded according to requirement [REQPROD 346800]. |
| 0x01 | Normal message | The payload (data) is send without any encoding. The data is packed in byte order or as defined in corresponding SWRS which defines how the data shall be packed. |
5.4 OperationType
| Number | Friendly Name | Description | ACK |
|---|---|---|---|
| 0x00 | REQUEST | Request where a response is necessary. E.g. The client uses a REQUEST to get the value of a property from the server. The value is returned to the client in a RESPONSE message from server. | yes |
| 0x01 | SETREQUEST_NORETURN | A message that does not require any response from the receiver. Using UDP, this OperationType is only used in conjunction with notification messages. E.g. set a new value. | yes |
| 0x02 | SETREQUEST | A combined message that performs two operations into one namely Set and Get. First, the client sets a new value and waits for the response consisting of the updated value. | yes |
| 0x03 | NOTIFICATION_REQUEST | A request of a notification/event callback. Used to request to subscribe on a property, either cyclic or event based. | yes |
| 0x04 | RESPONSE | The RESPONSE message for a REQUEST . E.g. the status message containing the current value. | yes |
| 0x05 | NOTIFICATION | Notifications are typically used when an application subscribes on a certain parameter which is sent on events for this notification type. The receiver of a message of this notification type shall respond with an ACK message. | yes |
| 0x06 | NOTIFICATION_CYCLIC | This notification type is sent cyclically according to the requested period, and shall not be acknowledged (that is NOT responded with an ACK) by the received. | no |
| 0x07 | 0x6F | Reserved by IP API Template. | ||
| 0x70 | ACK | Acknowledgement for UDP messages. The sender/receiver shall make use of the SenderHandleID (and the IP source address) to identify/distinguish which message to send/receive acknowledgement on. Note: The acknowledgment messages do not carry any payload. | no |
| 0xE0 | ERROR | This message type is a response containing an error message. The first payload byte, consists of the 8 bit ERRORCODE followed by 16 bit ERRORINFORMATION . More information regarding general error codes can be found in chapter [4.5 General Error Codes]. This operation type shall NOT be responded to with ACK messages. | no |
5.5 NOTIFICATION_REQUEST
| TYPE | Friendly Name | Description |
|---|---|---|
| 0x00 | 0x04 | RESERVED | Reserved for future usage. |
| 0x05 | NOTIFICATION | Request to activate subscription on specific OperationID(s) according to VALUE. |
| 0x06 | NOTIFICATION_CYCLIC | Request to activate subscription on specific OperationID(s) according to VALUE. |
| 0x07 | 0xFD | RESERVED | Reserved for future usage. |
| 0xFE | STOP SPECIFIC SUBSCRIBTION | Stops subscription on a specific VALUE. |
| 0xFF | STOP ALL SUBSCRIBTIONS | Stops all subscription on the message used SERVICEID. |
5.6 ERROR Code
| ErrorCode | ErrorCode Description | ErrorInformation | Description |
|---|---|---|---|
| 0x00 | Not Ok | / | An unspecified error occurred. |
| 0x01 | ServiceID not available | Return the ServiceID | The Service is not available or does not exist. |
| 0x02 | OperationID not available | Return the OperationID | The Operation is not available or does not exist. |
| 0x03 | OperationType is not available | Return the OperationType | Invalid OperationType. |
| 0x04 | Invalid protocol version | Return the supported Protocol Version | Invalid protocol version, return the supported Protocol Version. |
| 0x05 | Processing | / | This error code indicates that the requested operation ID is already processing a previous request. More information in [REQPROD 381391]. |
| 0x06 | Invalid Length | / | The length of the message is not correct. |
| 0x07 | Application Error | / | Application not ready. |
| 0x08 | Timeout | / | Timeout occurred. |
| 0x09 | Busy | / | The server is concurrenty handling maximum number of messages according to [REQPROD 347046] and cannot process the message. Retry after time according to [REQPROD 347066]. |
| 0x0A | 0x1F | RESERVED | / | Reserved for generic errors. |
| 0x20 | 0x3F | RESERVED | Specific Errorinformation for OperationIDs | Reserved for specific errors of services and operations. |
5.7 DEFAULT WFA AND WFR values
| defaultTimeoutWFA | 500ms |
|---|---|
| increaseTimerValueWFA | 1.5 |
| numberOfRetriesWFA | 6 |
| defaultTimeoutWFR | 500ms / (1s) |
| increaseTimerValueWFR | 2 |
| numberOfRetriesWFR | 2 |
Note: The parameter value shall be adjustable via a local configuration file within each ECU that uses the IP command bus.