Java Network Programming--analysis of the implementation principle of Web server and browser

We basically go through a Web browser every day, going through some news, watching videos and the like.

As we all know, this is the so-called B/s structure (browser/server, browser/server mode), is the web after the rise of a network structure pattern, web browser is the client's most important application software.

That's it. Simply look at what the basic implementation principle is for a Web server such as a well-known Tomcat and a browser.

The first thing to be clear is, for example, what we do is to enter an address through the browser, to access a Web page operation.

The actual underlying operation is simply to say that the client (browser) is communicating with the Web server for network traffic.

So, since it is network communication. For Java, the socket and IO stream are naturally inseparable. In fact, this is the Web server and browser based on the principle of implementation.

Of course, to develop a well-established Web server or browser, the work that needs to be done is very complex. But here, what we want to know is just the principle.

We know that when you deploy a Web project that you develop to a Tomcat server, you can access the resources on the server through the browser.

But the important point is that there are different browsers developed by various vendors. However, all types of Web browsers can access the resources on the Tomcat server normally.

To this, we can understand that: I developed a Web server, and can ensure that other developers of the client will be able to communicate with my server properly.

The premise of being able to do this is that you have to develop a specification and that the client that wants to communicate properly with the server you are developing follows this specification.

This specification, the so-called protocol.

So, as in network communication, the transmission of data can follow the same TCP/IP or UDP protocol.

The Web server communicates with the Web browser, and also through a language that is familiar to both parties.

This is the Protocol: Hypertext Transfer Protocol, the HTTP protocol.

The difference is that TCP/IP and UDP are communication protocols in the transport layer, and the HTTP protocol is the protocol in the application layer.

So, when we want to implement so-called Web communication using the Java language, we should naturally follow the HTTP protocol.

Java has provided us with such an implementation specification, which is well-known: the Servlet interface.

When we develop a Web project, the most commonly used HttpServlet class is the specific subclass that is implemented based on this interface.

This class encapsulates and provides a common method for accessing and manipulating content that is based on HTTP protocol communication.

Having said so much, we pass some small examples to facilitate a more figurative understanding.

First, we look at the request for Web communication based on the HTTP protocol through a simple servlet code:

public class Servlettest extends HttpServlet {public void doget (HttpServletRequest request, httpservletresponse response ) throws Servletexception, IOException {for (Enumeration E = Request.getheadernames (); e.hasmoreelements ();) {String Header = (string) e.nextelement (); if (header = null) System.out.println ((New StringBuilder (String.valueof ( header)). Append (":"). Append (Request.getheader (header)). toString ());}} public void DoPost (HttpServletRequest request, httpservletresponse response) throws Servletexception, IOException {}}

in the above code, our aim is to pass the method in the Httpserlvetrequest,

To print the details of the encapsulated HTTP request in a Web browser-initiated request based on an HTTP protocol. The results of the program output are as follows:

The request for an HTTP protocol typically consists of three parts:

• Method/Uniform Resource Identifier (URI)/protocol/version
  
• Request headers
• Entity body

The method is the so-called Get/post method, the Uniform Resource identifier is the path of the target resource to be accessed, including the Protocol and Protocol version, which is placed on the first line of the request.

Subsequently, the request header is immediately followed by the request header; typically contains useful information related to the client environment and the request entity principal.

Finally, there is a blank line between the header and the entity body. It is important for the HTTP request format, and the empty line tells the HTTP server that the entity body starts here.

As already mentioned, what we want to study here is the basic implementation principle of Web server.

Then we naturally want to implement the so-called Web server, we already know:

The so-called B/s structure is actually the network communication between client and server based on HTTP protocol.

Well, it must be inseparable from the socket and Io, so we can simply simulate a most simple feature of the Cottage browser:

public class Mytomcat {public static void main (string[] args) {try {serversocket tomcat = new ServerSocket (9090); SYSTEM.OUT.PRINTLN ("server Start");//socket s = tomcat.accept ();//byte[] buf = new Byte[1024];inputstream in = S.getinputstream ();//int length = In.read (BUF); String request = new string (buf,0,length);//system.out.println (request);} catch (IOException e) {//TODO auto-generated catch Blocke.printstacktrace ();}}}

this time we are accessing our cottage server through the corresponding URL in our browser, and the resulting output is:

Through the results we have seen that we have succeeded in simply shanzhai a bit of tomcat.

However, it is important to note that in our own cottage Tomcat server, the reason for the successful output of the HTTP protocol request body, because:

We have access through a Web browser, and if the connection to the ServerSocket is accessed through a normal socket, there is no such request information.

As we have said earlier, the communication between the Web browser and the server must follow the HTTP protocol.

Therefore, our daily use of the Web browser, will automatically for our request for the HTTP protocol-based packaging.

However, because we already know the principle, we can also simulate the browser to be very enjoyable:

Cottage Browser public class Mybrowser {    public static void Main (string[] args) {         try {            socket browser = new Socket ("192.168.1.102", 9090);            printwriter pw = new PrintWriter ( Browser.getoutputstream (), true);            //package Request first line             pw.println ("get/http/1.1");             //Package Request Header             pw.println ("user-agent:java/ 1.6.0_13 ");            pw.println (" host:192.168.1.102:9090 ");             pw                     .println ("accept:text/html, Image/gif, Image/jpeg, *; Q=.2, */*; Q=.2 ");            pw.println ("connection:keep-alive");             //blank line             pw.println ();             //encapsulated entity body             pw.println ("username=zhangsan&age=17");            //Write complete             browser.shutdownoutput ();                                    //Accept Server return information,            inputstream in = Browser.getinputstream ();            //             int length = 0;         &nbsP  stringbuffer request = new StringBuffer ();            byte[] buf = New byte[1024];            //             while (length = In.read (BUF))! =-1) {                 string line = new String (buf, 0, length);            & nbsp;   request.append (line);            }            system.out.println (Request);             //browser.close ();        } catch (IOException e) {            system.out.println ("Abnormal, damn!");         }finally{                &NBSP;&NBSP;   }    }}//Modified Cottage Tomcat Server public class Mytomcat {    public static void Main ( String[] args) {        try {             ServerSocket tomcat = new ServerSocket (9090);             SYSTEM.OUT.PRINTLN ("Server Startup");            //             socket s = tomcat.accept ();            //             byte[] buf = new byte[1024];       & nbsp;    inputstream in = S.getinputstream ();                         int length = 0;             stringbuffer request = new StringBuffer ();            while (length = In.read (BUF))! =-1) {                 string line = new String (buf, 0, length);         & nbsp      request.append (line);            }             //             SYSTEM.OUT.PRINTLN ("Request:" +request);            printwriter pw = new PrintWriter (S.getoutputstream (), true);            pw.println ("< Html> ");            pw.println (" 
We start the server first, and then run the browser to simulate the process of web browsing, first see the server side received the request information:


immediately after the server receives the request for processing, it returns the resource to the browser and then gets the output information :

As you can see, the return information we get in the cottage browser is actually the source code of an HTML file,
In our cottage browser, this information is only shown in plain text, because our cottage browser does not have the ability to parse the HTML language.
So, another important feature of the browser is that it can parse the Hypertext Markup Language. In fact, this is also the difficulty and focus of browser development.

The above output looks obviously uncomfortable, so that the cottage is still the pit father!
We still through the regular web browser, to try to visit our cottage server, the results found that the effect is much more handsome:
Incidentally, since the browser initiates an access request to the Web server, it encapsulates the corresponding HTTP request body.
So, corresponding, when the Web server finishes processing the browser request, returns the data, also has the corresponding encapsulation, is the so-called HTTP response body.
For example, if we modify the code of our cottage browser to connect to a real Tomcat server:
public class Mybrowser {public static void main (string[] args) {try {Socket browser = new So Cket ("192.168.1.102", 8080); PrintWriter pw = new PrintWriter (Browser.getoutputstream (), true);//Package request the first line pw.println ("get/http/1.1");// Encapsulates the request header Pw.println ("user-agent:java/1.6.0_13");p w.println ("host:192.168.1.102:8080");p w.println ("accept:text/html , Image/gif, Image/jpeg, *; Q=.2, */*; Q=.2 ");p w.println (" connection:keep-alive ");//Empty Line pw.println ();//Encapsulate Entity Body//pw.println (" username=zhangsan&age=17 ");//write Complete browser.shutdownoutput ();//Accept the server return information, inputstream in = Browser.getinputstream ();//int length = 0;  StringBuffer request = new StringBuffer (); byte[] buf = new Byte[1024];//while ((length = In.read (BUF))! =-1) {String line = new String (buf, 0, length); Request.append (line);} SYSTEM.OUT.PRINTLN (request);//browser.close ();} catch (IOException e) {System.out.println ("abnormal, damn!");} finally{}}} 
To run the program, you will send the following output information:

Similar to HTTP requests, an HTTP response typically contains three parts:

 
 

  
  
 
   
Protocol/Response Code/Status Description: The protocol is also referred to as the HTTP protocol information, the response code refers to the processing results on behalf of the request code (such as the common 200, 404, 500), is actually the response of the request processing description
 
   
Response header: The response header also contains useful information similar to the header in the HTTP request.
 
   
Response entity: This is usually the HTML content of the response itself.
 
  
 
 
As with HTTP requests, the response header and the response entity are split with a blank line for easy interpretation.
At the same time, we can also find that the actual content that is actually parsed on the browser page is actually just the part of the response entity.
The response line and response headers are actually responsible for returning some useful information to us, but this is not something that needs to be shown in the browser.
In other words, our browser should have the ability to parse the HTTP protocol response in addition to the ability to obtain a full HTTP response.

In fact, Java also provides us with such objects as URLs and URLConnection objects.
If we are embedding such objects in our cottage browser for HTTP communication with the server, then:
public class MyBrowser2 {public static void main (string[] args) {try {URL url = new URL ("http://192.168.1.102:8080"); HttpURLConnection conn = (httpurlconnection) url.openconnection (); InputStream in = Conn.getinputstream (); byte[] buf = New Byte[1024];int length = 0; StringBuffer Text = new StringBuffer (); String line = Null;while ((length = In.read (BUF))! =-1) {line = new String (buf, 0, length); Text.append (line);} System.out.println (text);} catch (IOException e) {//TODO auto-generated catch Blocke.printstacktrace ();}}}
this time, when we run the program again, look at the output information and discover the input stream we get from the URLConnection object ,
Read the response information, as we wish, only the content of the response entity that needs to be parsed is displayed on the page.
In fact, this is what Java provides for us, which encapsulates the parsing capabilities of the HTTP protocol content.
And ultimately, we can basically imagine that urlconnection = Socket + HTTP protocol parser.
That is, the object's bottom layer, in addition to connecting through the socket to the Web server, also encapsulates the parsing capabilities of the HTTP protocol content.

So here we have a simple understanding of the basic principles of Web server and browser implementation.
Java Network Programming--analysis of the implementation principle of Web server and browser