北京工业大学毕业设计（译文）The DIL/NetPCs DNP/1110 Using the Embedded LinuxWeb Server for Embedded SystemsAfter the “everybody-in-the-Internet-wave” now obviously follows the“everything-in-the-Internet-wave”. The most coffee, vending and washing machines are still not available about the worldwide net. However the embedded Internet integration for remote maintenance and diagnostic as well as the so-called M2M communication is growing with a considerable speed rate.Just the remote maintenance and diagnostic of components and systems by Web browsers via the Internet, or a local Intranet has a very high weight for many development projects. In numerous development departments people work on completely Web based configurations and services for embedded systems. The remaining days of the classic user interface made by a small LC-display with front panel and a few function keys are over. Through future evolutions in the field of the mobile Internet, Bluetooth-based PANs (Personal Area Networks) and the rapidly growing M2M communication (M2M=Machine-to-Machine) a further innovating advance is to be expected.The central function unit to get access on an embedded system via Web browser is the Web server. Such Web servers bring the desired HTML pages (HTML=Hyper Text Markup Language) and pictures over the worldwide Internet or a local network to the Web browser. This happens HTTP-based (Hyper Text Transfer Protocol). A TCP/IP protocol stack that means it is based on sophisticated and established standards manages the entire communication. Web server (HTTP server) and browser (HTTP client) build TCP/IP-applications. HTTP achieved a phenomenal distribution in the last years. Meanwhile millions of user around the world surf HTTP-based in the World Wide Web. Today almost every personal computer offers the necessary assistance for this protocol. This status is valid more and more for embedded systems also. The HTTP spreads up with a fast rate too.14The DIL/NetPCs DNP/1110 Using the Embedded Linux1. TCP/IP-based HTTP as Communication PlatformHTTP is a simple protocol that is based on a TCP/IP protocol stack (picture 1.A). HTTP uses TCP (Transmission Control Protocol). TCP is a relative complex and high-quality protocol to transfer data by the subordinate IP protocol. TCP itself always guarantees a safeguarded connection between two communication partners based on an extensive three-way-handshake procedure. As a result the data transfer via HTTP is always protected. Due to the extensive TCP protocol mechanisms HTTP offers only a low-grade performance.Figure 1: TCP/IP stack and HTTP programming modelHTTP is based on a simple client/server-concept. HTTP server and client communicate via a TCP connection. As default TCP port value the port number80 will be used. The server works completely passive. He waits for a request(order) of a client. This request normally refers to the transmition of specific HTML documents. This HTML documents possibly have to be generated dynamically by CGI. As result of the requests, the server will answer with a response that usually contains the desired HTML documents among others(picture 1.B).GET /test.htm HTTP/1.1Accept: image/gif, image/jpeg, */* User selling agent: Mozilla/4.0Host: 192.168.0.1Listing 1.A: HTTP GET-requestHTTP/1.1 200 OKDate: Mon, 06 Dec 1999 20:55:12 GMT Server: Apache/1.3.6 (Linux)Content-length: 82Content-type: text/htmlTest-Seite Test-SeiteThe DIL/NetPCs DNP/1110 Using the Embedded LinuxListing 1.B: HTTP response as result of the GET-request from listing 1.AHTTP requests normally consist of several text lines, which are transmitted to the server by TCP. The listing 1.A shows an example. The first line characterizes the request type (GET), the requested object (/test1.htm) and the used HTTP version(HTTP/1.1). In the second request line the client tells the server, which kind of files it is able to evaluate. The third line includes information about the client- software. The fourth and last line of the request from listing 1.A is used to inform the server about the IP address of the client. In according to the type of request and the used client software there could follow some further lines. As an end of the request a blank line is expected.The HTTP responses as request answer mostly consist of two parts. At first there is a header of individual lines of text. Then follows a content object (optional). This content object maybe consists of some text lines in case of a HTML file or a binary file when a GIF or JPEG image should be transferred. The first line of the header is especially important. It works as status or error message. If an error occurs, only the header or a part of it will be transmitted as answer.2. Functional principl