International Journal of Engineering & Technology IJET-IJENS Vol:14 No:06 44

Transcription

1 International Journal of Engineering & Technology IJET-IJENS Vol:14 No:06 44 Data Traffic and Security over Internet via Monitoring and Analyzing the HTTP Protocol Ezmolda Barolli, Loren Nebiaj, Gloria Tyxhari Department of Statistics and Applied Informatics University of Tirana, Faculty of Economy Abstract -- Hypertext Transfer Protocol (HTTP) is a protocol that belongs to the application layer of the OSI model for collaborative, distributed and hypermedia information systems. Hypertext Transfer Protocol gets access to information through Transfer Control Protocol and Internet Protocol in an easy way. It is a stateless protocol with features like persistent connection and pipelining during the communication between clientserver. This paper aims to analyze hypertext transfer protocol: its concepts, communication, bit level description and analysis of the recording for HTTP captured data by WireShark. It aims to analyze in details a communication between the client and the server where the client transfers or receives a large amount of data to the server. Index Term-- Hypertext Transfer Protocol, Client, Server, World Wide Web, Uniform Resource Identifiers, Uniform Resource Locator, MIME. I. INTRODUCTION Protocols are predetermined rules that people use to communicate over one medium such as coaxial cable, optic fibers or wireless. A network protocol defines the conventions for exchanging messages between two entities on a network (White 2012, p.4). Nowadays, HTTP is one of the most widely used protocols on the internet or intranet. The fame came from the relation between that and World Wide Web, this because HTTP has grown along with the Web. On the other hand, HTTP is a language that helps web browser to communicate with web servers around the world. During Web communication, in particular is used Transmission Control Protocol (TCP). Internet Protocol (IP) is used for transferring packets from one node to another and TCP has responsibility for doing a reliable communication. HTTP protocol belongs to application-layer of OSI model and it is used to transmit and receive hypertext pages but not only. It can transfer files such as images, sound, video, and the other kinds of multimedia files. World Wide Web global information has used HTTP since In 1991 HTTP/0.9 was used as a first version of HTTP. It was a simple protocol, just for transferring data across the internet. It only had the method GET, which was for requesting a page from a server. Tim Lee and his project group wanted to expand HTTP/0.9 in another version with more operations and security. Those efforts concluded in recognition of HTTP/1.0 in In the same year, March 1996, some pre-standard of HTTP/1.1 was published. The statistics showed that 40% 65% of web browsers accessed their servers by using HTTP/1.1. The HTTP/1.1 was officially released in 1997 and some updates and improvements were made in The current version, still in use of HTTP is HTTP/1.1. In November 2012 a draft of HTTP/2.0 was released and there are several specific features in this version compared to the previous ones. This paper aims to analyze hypertext transfer protocol. The paper involves a theoretical and practical analysis. By theoretical analysis we do mean an explanation of all common and specific concepts related to that. These concepts are very important during the communication between two end nodes, client in one side and server on the other side. By practical analysis we do mean a deep analysis of each byte of HTTP packet. We have several packets and we will analyze some of them in order to give a practical explanation for theoretical concepts that we will describe at first part. This paper aims to represent how HTTP protocol uses some basic operations in order to handle the communication. HTTP version 2.0 was published on 14 April 2013 but again it was just a draft and not a serious project. This means the network technicians are working for that and information about HTTP 2.0 are very restricting. So, we have not included this version in our theoretical and practical analysis. II. ANALYZING HYPERTEXT TRANSFER PROTOCOL II.1. HTTP versions and their difference HTTP/1.1 was created to fix the known problems of HTTP/1.0, so this protocol was improved by adding some extra concepts in it. First of all is the hop-by-hop mechanism that means a request is sent to the origin server and a response is turned back to the client. An Origin server is a server on which a given resource resides or is to be created. (Berners - Lee, Fielding and Frystyk 1996, p.7). There are some intermediary devices across the network such as switches, routers or firewalls. The HTTP message travels through them. The second is transfer coding which means the client sends a coded document to the receiver without any alternation by the intermediaries. Then the receiver decodes this document that was compressed by the client. HTTP/1.1 solves the problem of safe message transmission by transfer coding mechanism. The third concept adopted by HTTP/1.1 is about virtual hosting. HTTP/1.1 offers the persistent connection mechanism. The aim was to eliminate multiple parallel connections. The number of TCP setup is reduced by establishment of a persistent connection. A client is sending a HTTP request to a server and is waiting for response from the server. During this

2 International Journal of Engineering & Technology IJET-IJENS Vol:14 No:06 45 time it is not establish another TCP connection, but the next request is going to be in the same persistent connection The protocol version is needed because it allows the sender to show the format of a message and its capacity to understand HTTP communication. All HTTP versions till now are HTTP/0.9, HTTP/1.0 and HTTP/1.1 which is the current version of HTTP. The original version of HTTP was called HTTP/0.9 and it did not require the use of TCP connection. HTTP currently requires TCP connection, but could run over any connection oriented service which is approximately the same with TCP. HTTP/1.0 standard was replaced by HTTP/1.1 standard because it had performance and scalability problems. HTTP/1.0 was connectionless protocol. The latest version improved some aspects such as extensibility, performance and security of the protocol. The changes between the latest two protocols are mostly on persistent connection, the host header and authentication procedures. In the table below are depicted some differences related to methods available in HTTP versions. Table I Methods available in HTTP versions. Method HTTP/0.9 HTTP/1.0 HTTP/1.1 CONNECT No No Yes DELETE No Yes Yes GET Yes Yes Yes LINK No Yes No POST No Yes Yes PUT No Yes Yes sending back responses. (Berners - Lee, Fielding and Frystyk 1996, pp. 6-7). All communication in the web is based on the HTTP, but HTTP is based on Transfer Control Protocol or Internet Protocol. Hypertext is a nonlinear writing or linking related documents for navigation. (Krishnamurthy and Rexford 2001, p.10). In this section we are going to briefly point out the key properties of HTTP which are: Global URI, Request response exchange and Statelessness. Reliability in a global URI: HTTP relies on the Uniform Resource Identifier (URI) naming mechanism. A URI is thus a formatted string from the protocol s point of view. (Krishnamurthy and Rexford 2001, p.176). The URI helps HTTP to identify resources on the Web or denotes a resource independent from its current location. It is a combination of a Uniform Resource Locator (URL) and a Uniform Resource Name (URN). URL represents the address of a file that is saved in the Web Server and it can be accessed in the internet. We can find the location of resources via URL, but URN is used for identification. So, a particular URI can be represented by a name or by a locator or by both at the same time. URL is the most popular form of URI. There are two kinds of URI, relative and absolute. The string of an absolute URI starts with a scheme and is followed by a string that represents the source that can be reached via the scheme. This scheme designates the protocol and this protocol is used to access the resource. The string of the relative URI does not start with scheme. This is the difference between a URI relative and absolute. The most regularly scheme for using on the Web is http. Each scheme has a different syntax from others and mechanism to name resources. Request-Response exchange: The figure below represents a scenario where a HTTP client intends to contact to a HTTP server through a HTTP proxy server. As we can see from table 1 the latest version of HTTP has more features comparing to the others, which means that it has improved a lot of things compared to the earliest version. In the above table we have not included version 2.0 of HTTP because it is not completed yet, this based on the draft that will expire on 1 May, 2015 [17]. A little bit information was also published on 14 April 2013 by (Belshe M., and Peon R., 2013.) where it is stated that: The HTTP/2.0 encapsulation enables more efficient use of network resources and reduced perception of latency by allowing header field compression and multiple concurrent messages on the same connection. It also introduces unsolicited push of representations from servers to clients. II.2. Protocol properties HTTP is a relatively simple client - server mechanism for accessing documents anywhere in the Internet. Client is an application program that establishes connections for the purpose of sending requests. Server is an application program that accepts connections in order to service requests by Fig. 1. The client server communication with an intermediary proxy server. In this case, the client intends to request an object of the Back End Server through the Proxy Server. Basically, the client sends the request to the proxy server which sends the request to the Back End Server. The proxy adds its identity to the request received from the client. When the Back End Server receives the request from the client (through the Proxy server), it treats the request as if it had come directly from the client and sends back the response to the client (in this example, through the proxy server again). The proxy server will include its identity to via header in the response from the Back End Server also. Due to this, both the client and the server will

3 International Journal of Engineering & Technology IJET-IJENS Vol:14 No:06 46 know what the path is taken by the request and the response respectively. It is taken for granted the fact that a TCP connection is required before the transmission of HTTP messages between clients and servers. Statelessness of the protocol: HTTP is a stateless protocol; this means the lack of state maintenance across client server pairs. So, after the HTTP server has responded his answer to the HTTP client, the connection between them is dropped. HTTP uses some components during the communication mechanism. These components can maintain state about past requests and responses. One example that shows the stateless of the protocol is when a user wants to view three web pages. In this case, for each web page, by the web browser will be created three HTTP request. The protocol itself does not have any awareness about previous requests, but the client and the server might have awareness about them. Statelessness is a disadvantage for HTTP protocol but it ensures Web scalability. The lack of HTTP s state is a problem for some applications, like e-commerce. A legal transaction requires some states to be maintained across HTTP requests. The role of MIME in HTTP: Multipurpose Internet Mail Extension (MIME) was proposed for sending multiple objects within a single message. These objects can be both, textual or non-textual such as sound, video, image etc. So, MIME defines a variety of multimedia data objects. MIME is also used to represent text in non-ascii character set. There are some differences between MIME and HTTP. The main difference is: MIME was designed for exchange service whereas HTTP was designed for high performance over binary connections, client server architecture. HTTP has adopted some concepts from MIME. The first is classification of data formats in communication between senders and receivers. MIME type is the data format for HTTP. Another concept that HTTP has adopted from MIME is its formats for multipart messages. This implies the ability of MIME to include a lot of entities in a message body. There are some MIME concepts that are not adopted by HTTP. The main concept is the way of addressing external documents. II.3. Security Consideration The HTTP s procedures offer some necessary security services but not everything. Some specific security services are required in the critical cases. Security ensures that only authenticated users can access the server. The main disadvantage of World Wide Web is that HTTP protocol does not provide any manner to encrypt the messages to protect the privacy. So an adversary can eavesdrop the confidential information during the client-server communication. The Web has developed a technology to provide the confidentiality. HTTP client and HTTP server during the communication agrees to continue communication with a secure version of HTTP, such as Hypertext Transfer Protocol Secure (HTTPS). In all cases HTTPS is combination of HTTP with Secure Sockets Layer (SSL). HTTPS is a protocol that uses SSL for transporting the HTTP message. (Krishnamurthy and Rexford 2001, p.210). SSL involves encryption and secure identification of the server because it is the most popular network security technology on the world. So the communication mechanism between HTTP client and HTTP server is very secure because everything in the communication is encrypted, including URI. Fig. 2. The difference between standard HTTP and HTTP secured with SSL Standard HTTP HTTP secured with SSL As we can see from the figure 1, SSL is placed between HTTP and TCP. So, firstly HTTP has to communicate with SSL and then SSL communicates with TCP transport layer. The client should decide in which communication with server to use SSL. If it will use SSL then the standard URI scheme will begin with https which indicates a secure session. HTTP with SSL has a default port 443. In each communication if the HTTP client uses SSL are needed two TCP ports, one for nonsecure operation (port 80) and another for secure operation (port 443). III. SOFTWARE COMPARISON FOR MONITORING DATA TRAFFIC OVER THE INTERNET Before we start using a specific program for monitoring and analyzing network data, we need to identify which program best serves to our purposes. For this reason we have consider two of the most commonly used programs from the network administrators: Tcpdump and WireShark. Both programs are offered free on the Internet. Tcpdump is a utility for studying network protocols. It is an excellent tool for analyzing the network, widely used in UNIX or Linux. This program pick up the packet based on several criteria selected by the user by writing commands in the command line, this traffic can be registered in different formats. WireShark is the graphic application widely used to monitor and analyze network. It is open-source program and can be executed in several platforms such as UNIX, Linux and Windows. The file with traffic packets captured by Tcpdump can read by using WireShark. It contains advanced filtering options, provides us with statistics and graphics, it also offers a view of the flow of communication between the end nodes. Doing a comparison between these two programs we can say that it is better using WireShark than Tcpdump. Another reason added to this statement is that in the case of this analysis we are using Windows as an operating system so monitoring and analyzing with Tcpdump would be difficult.

4 IV. DATA TRAFFIC ANALYSIS International Journal of Engineering & Technology IJET-IJENS Vol:14 No:06 47 IV.1. GET analyze (Packet byte analyze) No. : 7 Time: Source: Destination: Protocol Length Info: HTTP 345 GET / HTTP/1.1 Abs time and date: :19: This information is not completely related to HTTP but also to TCP, IP, Ethernet and Data Link Layer. We are going to give a short background about this single packet. The information above is describing the number of packet, the time when it was sniffed and in reference of the packet number 0, the IP address of HTTP client and server, the type of protocol, the length and the name of method that it used during the communication. Frame 7: 345 bytes on wire (2760 bits), 345 bytes captured (2760 bits) Ethernet II, Src: Vmware_75:7e:7d (00:0c:29:75:7e:7d), Dst: Vmware_e4:aa:93 (00:50:56:e4:aa:93) Internet Protocol Version 4, Src: ( ), Dst: ( ) Transmission Control Protocol, Src Port: (41179), Dst Port: http (80), Seq: 1, Ack: 1, Len: 291 As far as WireShark is giving information not only for HTTP but for all the protocols that encapsulate this protocol, in the next packet this information that is above will be omitted 1. Hypertext Transfer Protocol 2. GET / HTTP/1.1\r\n 3. [Expert Info (Chat/Sequence): GET / HTTP/1.1\r\n] 4. Request Method: GET 5. Request URI: / 6. Request Version: HTTP/ Host: 8. User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:18.0) Gecko/ Firefox/18.0\r\n 9. Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/ *;q=0.8\r\n 10. Accept-Language: en-us,en;q=0.5\r\n 11. Accept-Encoding: gzip, deflate\r\n 12. Connection: keep-alive\r\n 13. \r\n 14. Full request URI: The first line shows the name of the protocol which in our case is Hypertext Transfer Protocol. The second line contains method, version of protocol, two characters n and r. The method is defined as GET. GET is a method used to retrieve any object from the server. The version of HTTP is defined as 1.1 which is the current version of this protocol. The characters \r, \n are defined as the line break in the protocol specification. Everything that is written between brackets is added by WireShark. So we are not going to comment the third line. The forth line informs about the required method which in this case is settled as GET. Line number five is the request URI: / because of the HTTP protocol we cannot send a request URI empty. So, instance of this it is used the backsplash symbol, /. In line number six is defined the version of 1.1 of HTTP. A more detailed description about this is given in one of the above section. In the seventh line the host is settled as This means that HTTP client is sending a request to yahoo server. In the eighth line we see that user have used Mozilla Firefox as web browser running in an operating system, X11; Ubuntu; Linux x86_64; rv:18.0. If we look in WireShark, in the Ethernet part, we will understand that it is running over the Virtual Machine. We see the name of Virtual Machine is Vmware. In the ninth line, are mentioned the formats that the client will accept from the server. In this case, text/html,application/xhtml+xml,application/xml; with a quality of 0.9 (which means that these formats are more preferable than the others above),*/* and other formats with quality of 0.8. In the tenth line the accept language is settle to en or en-us, following the ISO index. In the eleventh line is settled the accept-encoding, which means that the client will accept the following compress formats: gzip, deflate. In the twelfth line the connection is settle as keep-live, which means that the client will require continuous packets from the server to be sure that the connection between both is on. In the fourteenth line it is written the URI of the server that is trying to reach. 1. HTTP/ Found 2. Date: Mon, 18 Feb :19:41 GMT 3. Set-Cookie: B=780qj418i56nd&b=3&s=g6; expires=thu, 19-Feb :19:41 GMT; path=/; domain=.yahoo.com 4. P3P: policyref=" CP="CAO DSP COR CUR ADM DEV TAI PSA PSD IVAiIVDiCONiTELoOTPi OUR DELiSAMiOTRiUNRiPUBi IND PHY ONL UNI PUR FIN COM NAV INT DEM CNT STA POL HEA PRE LOC GOV" 5. Cache-Control: private 6. X-Frame-Options: SAMEORIGIN 7. Set-Cookie: IU=deleted; expires=sun, 19-Feb :19:40 GMT; path=/; domain=.yahoo.com 8. Set- Cookie:fpc=d=mmilkbmXtTVcbgX0doDt0N9QZ7o6zVmm o6e95fmiahe5psnxgna6ocihpzb3faijqky3iw3uxofiu chj6zjjhw8l1bhiczd0mhhy_ynqoptrerwdpn.kszos_xas

5 International Journal of Engineering & Technology IJET-IJENS Vol:14 No:06 48 hnzefspfzfwladdo_zfvkjx1ibn7bcrinfir1ji00uk.qf7n gy9kgux6rvltcz70cfh2rgcujfc-&v=2; expires=tue, 18-Feb :19:41 GMT; path=/; domain= 9. Location: Vary: Accept-Encoding 11. Content-Type: text/html; charset=utf Age: Transfer-Encoding: chunked 14. Connection: keep-alive 15. Server: YTS/ In the first line we see the name of the protocol and its version - HTTP/1.1/. It also settled the status code which in this case is 302 Found. The request resource is under a different URI. The temporary URI must be given in the location file of the response. In the second line it is defined the date, location and hour of the response. In the third line Set-Cookie is defined with an expire time, a path and a domain. This means that the server is giving a cookie to the client in order to recognize him. The value of the path is / which means that it is empty. The domain was yahoo.com. In the fourth line, P3P is settled with some specifications and it is used to inform the clients that the server is going to use the information that it collects from the browsers. In the fifth line the cache control is on private and this means that the server will keep a copy but it will not share it with other servers. In the sixth line the X-frame options has in his value the same option which means the document will be shown in a frame only if the frame and its parent have the same origin. In the seventh and eighth line, the server is giving extra cookies to the client with the same path and different expire times. This, as we have mentioned before, means that the user is generating static information as he is navigating the web. In the ninth line is setting the location of the server. In the tenth line the server has added the Vary header in the response message. This causes the proxy to cache multiple versions of the request, one for each value of the Accept - Encoding request header. Sometimes the Vary: Accept Encoding header is added to provoke the correct behavior from the proxy server. In the eleventh line the server will send text and html as formats. In the twelfth line the server is estimating the time since the server generates the response. In the thirteenth line we can see transfer encoding. This represents values that are used to show an encoding transformation that has been or can be applied to a message body in order to make sure a safe transport via the network. The chunked transfer encoding must be applied only one time to a massage body. When it is used it must be the last transfer encoding applied to the message body. In the fourteenth line the connection is settled as keep-live which means that the server and the client can communicate on an existing connection. In the fifteenth line we can see the name of the server that is responding to the HTTP client which in this case named YTS. It contains information related to the software which is used by server to handle the request. IV.2. POST analyze (Packet byte analyze) The analysis of recording in the previous section has included only GET method. This happened because in the communication between the client and the server only the client wanted information from server. The aim is to analyze a communication between the client and the server where the client transfers a large amount of data to the server. To do this we need to analyze packets that involve POST method. In this section is examined a communication between client and server via POST method. The detailed information and analysis for two packets are as follows No. : 196 Time: Source: Destination: Protocol Length Info: HTTP 4935 POST /ethereal-labs/lab3-1-reply.htm HTTP/1.1 Abs time and date: :55: As we can see the number of packet that we analyze is 196. The IP address of client is and the IP of server where client is transferring data is We understand the client is transferring data because the method is POST and it is corresponding for uploading data to the server. The last information we can see is time and data when we captured data by WireShark. 1. Hypertext Transfer Protocol 2. POST /ethereal-labs/lab3-1-reply.htm HTTP/1.1\r\n 3. Expert Info (Chat/Sequence): POST /ethereal-labs/lab3-1-reply.htm HTTP/1.1\r\n 4. Request Method: POST 5. Request URI: /ethereal-labs/lab3-1-reply.htm 6. Request Version: HTTP/ Host: gaia.cs.umass.edu 8. Connection: keep-alive 9. Content-Length: Cache-Control: max-age=0 11. Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q = Origin: User-Agent: Mozilla/5.0 (Windows NT 6.1) AppleWebKit/ (KHTML, like Gecko) Chrome/ Safari/ Content-Type:multipart/form-data;boundary=---- WebKitFormBoundaryLna6B7NHOVgRhBfy 15. Referer:

6 International Journal of Engineering & Technology IJET-IJENS Vol:14 No: Accept-Encoding: gzip,deflate,sdch 17. Accept-Language: nb- NO,nb;q=0.8,no;q=0.6,nn;q=0.4,en-US;q=0.2,en;q= Accept-Charset: ISO ,utf-8;q=0.7,*;q=0.3 The first line shows the name of the HTTP protocol. The second line contains the name of the method that is used for communication, request URI and the version of HTTP protocol. The same information is shown from third line to sixth line. We are not going to comment the third line because the information between brackets is added by WireShark. In the seventh line the host is settled as gaia.cs.umass.edu. In the eighth line the connection is settle as keep-live, which means that the client will require continuous packets from the server to be sure that the connection between both is on. In the ninth line we can see the content-length This means the size of the entity-body, in decimal number of OCTETs. In line number ten we see the browser telling the server that it needs the current version of the file and not to server a version that was cached somewhere along the path. We can understand that from the value of max-argue which is 0 seconds. In line number eleven, are mentioned the formats that the client will accept from the server. In this case, text/html,application/xhtml+xml,application/xml; with a quality of 0.9 (which means that these formats are more preferable than the others above),*/* and other formats with quality of 0.8. The twelfth line shows the URL address of the origin server which is the server on which a given resource is to be created. In line number thirteen we see that user have used Mozilla 5/0 as web browser running in an operating system, Windows NT 6.1. In line number fourteenth is described the type that would be accepted in the object that is added in the body. multipart/form-data allows the user to send-upload files using the POST. It is an encoding type. It is also define the boundary of the file that is being uploaded. In line number fifteenth the referrer request header field allows the client to specify the URI address of the resource from which the Request URI was obtained. In the sixteenth line is settled the accept-encoding, which means that the client will accept the following compress, formats: gzip, deflate, sdch. The line number seventeen, the accept language is explained in the preceding parts which restricts the set of natural language that are preferred as a response to the request. The set of languages that are allowed now is increased in comparison with the case when we analyzed GET method. The line number eighteen shows the accept-charset field which means what character sets are acceptable for the response. We can see ISO standard there and US-ASCII character set is assumed to be acceptable to all HTTP client. 1. HTTP/ OK 2. Date: Fri, 19 Apr :55:36 GMT 3. Server: Apache/2.2.3 (CentOS) 4. Last-Modified: Thu, 07 Jun :06:48 GMT 5. ETag: " a0-b0d93600" 6. Accept-Ranges: bytes 7. Content-Length: Keep-Alive: timeout=10, max= Connection: Keep-Alive 10. Content-Type: text/html; charset=utf-8 From the first line we understand that is a HTTP response which contains the version 1.1 of HTTP, response code 200 and response message OK. The meaning for these is described before. In the third line we can see the name of the server that is responding to the HTTP client which in this case named Apache. In line number four is last-modified response which indicates the data and time at which the origin server believes the information was modified. In this case is 7 June 2013 at 06:48 GMT. The fifth line shows ETag response header field which provides a unique value for a resource s contents. From the sixth line we can see that accept-range is in byte. This shows that the origin server supports byte range requests for the target resource. In line number seven we can see the size of content length is 416. The meaning of this field is described earlier. In line number eight, the server has selected a maximum of 100 requests, but will timeout if the next request is not received within 10 seconds. In line number nine the connection is settled as keep-live. In line number ten we can see again the content-type. In this case, the formats accepted by the user are text and html. The charset specify the set characters that are supported for a form. In this case is settled as UTF-8 (Transformation Format-8 bits). V. CONCLUSIONS HTTP has become one of the most popular protocols on communicating data and information through the web. The main reason for this is the high usage of World Wide Web. Another reason is that HTTP has also several characteristics such as persistence, pipelining, multiple connection and stateless. The versions and methods of HTTP protocols have evolved during the last 20 years from /0.9 to /1.1. It is anticipated that another version, HTTP Version /2.0 will be used after two or three years with more methods. These advantages make HTTP to be more favorable than its competitor Gopher protocol. HTTP is a very secure protocol by using SSL for encryption. The TCP port by default for this protocol is 80 whereas for HTTPS is 443. The communication between the HTTP client and HTTP server happens in two ways: directly as web browser - web server or indirectly via an intermediate proxy server. So, it works as a request - response protocol in the client - server model. The format of HTTP message is splitted in two parts, header and body. There are data inside them that will be transferred from client to server or vice - versa.

7 International Journal of Engineering & Technology IJET-IJENS Vol:14 No:06 50 From the analysis of the recording we noticed a Mozilla web browser sent a GET request to the yahoo server. The client intends to retrieve object from the yahoo server as XML text, applications. The client intends to access to yahoo website. This server then sends a response to the client with the status code 302 found, which means that the communication is successful. We can easily notice this communication by seeing IP address of the server and client as well as some specific options that are included in WireShark. In addition to these packets we captured, some other packets were analyzed via WireShark. We noticed a communication between client and server via POST message inside the second packets captured. In this communication the client uploaded a text file and server then sent it a confirmation message as response. Normally, during the communication between these end nodes are involved several other protocols and not only HTTP. [21] Krishnamurthy, B., and Rexford, J Web Protocols and Practice: HTTP/1.1, Networking Protocols, Cashing, and Traffic Measurement. Boston: Addison Wesley. [22] Mohamad, G Understanding server HTTP headers (Vary: Accept - Encoding). [23] URL: last access: [24] White J Introduction to the Hypertext Transfer Protocol (HTTP): What is a network protocol? Virginia Tech. [25] Thomas, S HTTP Essentials: Protocols for Secure, Scaleable Web Sites. New York: Wiley Computer. [26] Varnish Software, HTTP (2004). [27] URL: HTTP.html, last access: [28] Belshe, M., Peo, R., et.al. (2015) Hypertext Transfer Protocol version 2, draft-ietf-httpbis-https-latest. [29] URL: last accessed: REFERENCES [1] Benoist E, Web Security, Summer Term. HyperText Transfer Protocol - HTTP.IIG University of Freiburg. [2] URL: last access: [3] Belshe M., and Peon R Hypertext Transfer Protocol: draftietf-httpbits-http2-latest. [4] URL: last access: [5] Berners - Lee, T., Fielding, R., Gettys, J., Mogul, J., Leach, P. and Frystyk, H Hypertext Transfer Protocol -- HTTP/1.1.Massachusetts: Network Working Group. [6] URL: last access: [7] Berners - Lee, T., Fielding, R., and Frystyk, H Hypertext Transfer Protocol -- HTTP/1.0.Massachusetts: Network Working Group. [8] URL: last access: [9] Berners - Lee, T., Fielding, R., Gettys, J., Mogul, J., Leach, P. and Frystyk, H Hypertext Transfer Protocol -- HTTP/1.1.Massachusetts: Network Working Group. [10] URL: last access: [11] Brass S, Chapter 4: The HyperText Transfer Protocol. Universitat Halle. [12] URL: last access: [13] Buzzle (2012), HTTP Hypertext Transfer Protocol. [14] URL: last access: [15] Hypertext Transfer Protocol HTTP/1.1 (1996). [16] URL: spec-01.html, last access: [17] HTTP -- Hypertext Transfer Protocol. Department of Computer Science [18] URL: ttp.pdf, last access: [19] HTTP Gallery, HTTP Methods (2007). [20] URL: last access: