exercise 5

Following is the screen shots of the traffic captured by the wire shark while sending the mail.

The protocol used to perform the sending the mail while capturing the traffic is HTTP and TCP protocol. The IP address of the machine is 10.1.1.2 and the IP address of the mail server is shown as 66.102.11.19. while performing this task I found that the mail server I am using is in the secure communication and as well it is using the HTTP post command. According to the wire shark my system is using two protocol and they are TCP and HTTP protocol.

exercise 4

While capturing the live data from the web site www.google.com, found the following informations.

The IP address 10.1.1.2 sends the request to 10.1.1.1 through the DNS. Here 10.1.1.1 is the IP address to the LAN port, and the IP address 10.1.1.2 is the address of the machine which sends the request to the LAN port to access the www.google.com. Once the IP address 10.1.1.1 gets the request from the IP address 10.1.1.2 the IP address 10.1.1.1 sends the common name of the websites. While the IP address 10.1.1.2 gets the common name of the website then it sends the another query to the IP address 10.1.1.1 about the safebrowsing and ask to allow the IP address of the cname. Once the IP 10.1.1.1 gets the request it sends the IP address of the cname which is 66.102.11.101 and 66.102.11.100

once the IP address got the IP of the google it will directly sends the request to the IP of the google. While performing all this transaction both the IP were using the DNS protocol.

10.1.1.2 sends the request to the 10.1.1.1 throught DNS

10.1.1.1 sends the reply to the 10.1.1.2 through DNS

10.1.1.2 sends the request to the 10.1.1.1 through DNS

10.1.1.1 sends the reply to the 10.1.1.2 through DNS

Here as previously mention that the 10.1.1.2 is the IP address if the machine which sends the request and the IP address 10.1.1.1 is belongs to the LAN port of the machine.

To complete this transaction the system passes the 11 frames to get the required website by the machine.

Following is the screen shot of the Live capture

exercise 3 question C

Frame 6 is running under the Hypertext Transfer Protocol with the Get method. The data for the frame 6 is given below:
Request Method: GET
Request URI: /
Request Version : Http/1.1
Host: www.yahoo.com
Similarly frame 21 is running under Secure Socket Layer
RLSv1 Record Layer: application data protocol: http
content type: Application Data (23)
Version : TLS 1.0 (0x0301)
Length: 432
Encrypted Application Data: FE6B3CD259B796669F2767DF9972DCDA2541F030D9B3D4E9...
Due to the above information frame 21 can't read the same as in frame 6. Frame 6 is using HTTP to complete the transaction while the frame 21 is using the secure socket layer to complete the transactions.

exercise 3 question B

In row three there is no frame listed in row iii. The only frame listed on the row iii was 13-20 which belongs to the web page my.usf.edu. The main reason for not to listing the frame in row iii for the web page www.yahoo.com is that the there is no protocol performing in the row iii. If there is no protocol shown in the table given the destination and the source address will not know to send the request through which protocol.

exercise 3 question A

While comparing the TCP packet in the frame 3 and the frame 12 we found the following difference :
Frame 3:
Transmission Control Protocol, src port: omilink-port (3904), dst port:http (80), seq:0, len:0

Flags: 0x02 (SYN)
0... ....=congestion window reduced (CWR): not set
.0.. ....=ECN-echo: not Set
..0. ....=Urgent: not set
...0....=Acknowledgment: not set
.... 0...=Push:Not set
.... ..1.=Syn: set
.... ...0=Fin: not set
windows size= 65535
Checksum: 0x6405 [correct]
Options: (8 bytes)
Maximum segment size: 1406 bytes
NOP
NOP
SACK permitted


FRAME 12
Transmission Control Protocol, src port:mpl-gprs-port (3924), dst port: https (443), seq:1, ACK:1, Len=0
Flags : 0x10 (ACK)
0... .... = Congestion window reduced (CWR): Not set
.0.. .... = ECN-Echo: not set
..0. .... = Urgent: Not Set
...1 .... = Acknowledgment :set
.... 0... = Push : Not Set
.... .0.. =Reset: Not Set
.... ..0. = Syn: not set
.... ...0 = Fin: Not Set
Window size: 65535
Checksum: 0xa956 [correct]

[SEQ/ACK analysis]
This ACK was been segmented in frame 11. With the RTT to ACK and the Segment was: 0.000105000 seconds.

While comparing this two frame what we found is that the frame 3 is been segmented through byte process while the frame 12 is been segmented through the time process analysis. Frame 3 shows how much byte it will occur wile segment the and the frame 12 shows how many time they need to segment. In flags section the frame only sets for the SYN and the rest of the flags was not been set similarly in frame 12 Acknowledgment was been set and rest of the flag were not set.

exercise 2 question H

The frame 141 and frame 142 got same source address and request graphic file from the same destination IP address . The information on both the frame is HTTP//1.0 200 ok (GIF89a). Following are the information from which the client can differentiate in the image requested by the same IP address with the same kind of information.

FRAME 141:

Transmission Control Protocol, src port: http (80), Dst port: stgxfws (1226), seq: 15765, Ack:3930, len:1045

FRAME 142

Transmission Control Protocol, src port: http (80), Dst port: slinkysearch (1225), seq: 25777, Ack:4253, len: 863

The above information show the different data hold by the two frame with same source IP address and the same information. The destination port for frame 141 and 142 are different and the seq and the acknowledgment were different to each other. By this difference the client can differentiate the about the graphic to match with the get statement in the frame.

exercise 2 question G

In frame 139 the IP address 64.21.46.134 sends the request to the IP address 131.247.95.216 through the TCP protocol and the information given was that the segmented TCP will be reassembled PDU in frame 160. Similarly request send by the IP address 64.21.46.137 to the 131.247.95.216 and the information is acknowledgment and is been segmented in frame 133. This shows that the segmented TCP is not being reassemble in the frame 160. Similarly the information on frame 142 shows that in 134 the ACK is been segmented and not going to be reassembled in the the frame 160. But in the frame 143 the information given is bit different than the information in frame 141 and 142. The information on this frame is that ACK is been segmented in the frame 140 and will be reassemble the PDU in frame 160.
If the packets that are suppose to be reassembled do not arrive in a continuous stream than the the there will be error and the IP address could not send the proper data to the requested IP address. In this case the TCP will get the incorrect data or some time TCP error may caused due to checksum offload. This shows that the failure of the reassembled of the segmented data in different frames and fail to send requested data to the desired IP address.
For example: whenever we get the information like “page could not be displayed” in our web page is the example of this error.

exercise 2 question F

The comparison between Frame 42 and the frame 48 are mention below:
Frame 42
Hypertext Transfer Protocol
GET /us.yimg.com/i/ww/dsf_1.1.js HTTP/1.1\r\n
request method: GET
Request URI: /us.yimg.com/i/ww/dsf_1.1.js
Request Version: HTTP/1.1
Host: us.il.yimg.com\r\n
user -agent: mozilla/5.0
Accept: */*\r\n
Accept Encoding: gzip, deflate\r\n
Accept-Charset:ISO-8859-1, utf-8; q=0.7, * ; q=0.7\r\n
keep alive: 300\r\n
connection: keep-alive\r\n
Referer: http://www.yahoo.com/\r\n
\r\n
Now
Frame 48 got the following description
Hypertext Transfer Protocol
GET /us.yimg.com/i/ww/beta/y3.gif HTTP/1.1\r\n
Request Method: GET
Request URI: /us.yimg.com/i/ww/beta/y3.gif
Request Version: HTTP/1.1
HOST: us.il.yimg.com\r\n
User Agent: Mozilla/5.0
Accept: image/png,*/*; q=0.5\r\n
Accept-encoding: gzip, deflate \r\n
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7\r\n
keep Alive: 300\r\n
Connection: keep-alive\r\n
Referer: http://www.yahoo.com/\r\n
\r\n

While comparing these two information what we found is there is not much difference in both frames. Both frame is running HTTP protocol and request method is GET and using the same Request Version. The only difference is Accept method and the Request URI.
In accept method the Frame 42 can accept any kind of files with any extension while in the frame 48 the accept method shows that the all the image file should have the extension png. And the request URI has the different request.
Frame 42 request the Java script while the frame 48 request the .gif

exercise 2 question E

After doing the careful review of the frame 26 and frame 37 what I found the difference is in frame 26 the cname is us.js2.yimg.com and the cname in frame 37 is us.il.yimg.com, but the IP address for both cname is same as 131.247.92.200. While comparing the DNS with two frames the only difference is transaction ID. The Transaction ID for frame 26 is 0X409b and the Transaction Id for Frame 37 is 0xf0099.

exercise 2 question D

In frame 26 the IP address 131.247.95.216 sends the query to the IP address 131.247.92.200 by the help of DNS protocol. The information given on this frame to the DNS are mention below:
The query will be response in frame 27.
Transaction ID: 0x409b
Flags :0x0100 (standard query)
question: 1
Answer Rrs: 0
Authority Rrs: 0
Additional Rrs:0
Queries:
us.js2.yimg.com
type a, class IN
Similarly in Frame 27 the following information was obtain:
the query was requested in the frame 26.
Transaction ID: 0x409b
flags: 0x8180 (Standard query response, NO error)
Questions: 1
Answer Rrs: 5
Authority Rrs: 0
Additional Rrs: 0
Queries
us.js2.yimg.com
type a, class IN
The above mention data shows that the every component of the website was came from the same server name us.js2.yimg.com. Because all the information of both the frame 26 and 27 is same.

exercise 2 Question C

According to the network analyzer the website use the gzip to encoding the data. While encoding the data will automatically compress the data while sending. The website also enable to write the cookies. The description of the cookies is B=4foc9kt0p4mv5&b=2&f=v.

exercise 2 question B

According to the network analyzer the first two packet send by the IP address 131.247.95.216 to the IP address 131.247.92.200 is to get the common name and the IP address of the request website. In second frame the IP address 131.247.92.200 sends the common name and the IP address to the IP address 131.247.95.216. Once the IP address 131.247.95.216 gets the common name and the IP address of the website then it directly send the request to the cname and the IP address of the website. And the IP address of the websites gives the permission to view the website to the IP address 131.247.95.216.
In this way the IP address 131.247.95.216 can get the desired website from the network.
Total steps to view the desired website are mention below:
1.131.247.95.216 sends request to 131.247.92.200
2.131.247.92.200 replies to 131.247.95.216 with the cname and the IP address (216.109.117.106)
3.131.247.95.216 directly sends the request to the IP address 216.109.117.106 with the given cname of the website.
4.216.109.117.106 accepts the request send by the 131.247.95.216 to view the desired website.

exercise 2 Question A

In First few frame the IP address 131.247.95.216 sends request to the 131.247.92.200 to send the yahoo.com to the IP 131.247.95.216. While sending the reply to the IP address 131.247.95.216 from the IP address 131.247.92.200 gives the come information like 'common name of the website and the IP address of the website'. Here the common name of the website is www.yahoo.akadns.net and the IP address for that common name is 216.109.117.106. The two IP address of this website are mention below:

1^st IP address for website: 131.247.92.200 and

2^nd IP address for website : 216.109.117.106

These two IP address are the main IP for the website named www.yahoo.akadns.net as shown by the network analyzer.

exercise 1 question J

The network analyzer shows that the user was accessing a web page from the IP address 131.247.95.216 to the IP address 64.233.161.99.

exercise 1 question I

Here in frame 23 the IP address 131.247.95.216 sends a packet to the IP address 64.233.161.99 using the HTTP protocol to get the fevicon.ico in http/1.1. During this process the frame 23 got some error like checksum.
The checksum provided by the IP address 131.247.95.216 is 0xc7dd but the required checksums by the destination address is 0xe685. This type error may occur due to the TCP checksum offload. According to the SEQ and ACK analysis the acknowledgment to the segment in frame 22 with the RT to ACK was 0.040800000 seconds.
Similarly the IP address 64.233.161.99 sends the reply to the IP address 131.247.95.216 through TCP protocol or by using the Http protocol. In frame 24 the segmented TCP was reassembled PDU and in the frame 25 HTTP/1.1 200 ok (image/x-icon) shows that the address is been found and send to the IP address 131.247.95.216. But in Frame 26 the IP address 131.247.95.216 sends the packet to the address 64.233.161.99 using the TCP protocol. But the checksum used in this frame is incorrect.
The checksums used in this frame is 0xc636 it suppose to be 0x9d28. This could happen due to checksum offload. The ACK/SEQ analysis provide the following information about the ACK which is been segmented in frame 25 using the ETT to ACK the segment was 0.000100000 seconds.

exercise 1 question H

Followings are the individual description of the frames:

Frame 13:

Source: 64.233.161.99

Destination: 131.247.95.216

Protocol: TCP

information: TCP segment of a reassembled PDU

From the above information the packet send to the address 131.247.95.216 got the following descriptions:

Transmission control protocol, src port: http (80), dst port imyx (1143), seq:1652, ack:961, Len: 1430

Source port: http (80)

Destination port: imyx (1143)

Sequence number: 1652 (relative sequence number)

[Next sequence number: 3082 (relative sequence number)

Acknowledgment number : 961 (relative ack number)

header length: 20 bytes

Flag: 0x10 (ACK) which seems ok in this frame

Checksum: 0x736c which is define as correct by the analyzer.

SEQ/ACK analysis

This is an ACK to the segment in frame :12

.i.e. the RTT to ACK the segment was: 0.036996000 seconds

and the TCP Segment data is 1430 bytes.

This all data shows that the packet sends to the destination was segmented TCP which needed to reassembled using PDU (Protocol Data Unit).

Frame 14:

Source: 64.233.161.99

Destination: 131.247.95.216

Protocol: TCP

information: TCP segment of a reassembled PDU

From the above information the packet send to the address 131.247.95.216 got the following descriptions:

Transmission Control Protocol, src port: http (80) dst port: imyx (1143), seq: 3082, ack: 961, len: 1430

source port: http (80)

Destination port: imyx (1143)

sequence number: 3082 (relative sequence number)

next sequence number: 4512 (relative sequence number)

acknowledgement number: 961 (relative ack number)

header length: 20 bytes

flags: 0x10 (ACK) which ok in the frame 14 as well.

Checksum: 0xdfb5 [correct]

Reassembled PDU in frame: 22

TCP segment data 1430 bytes

The above information given by the analyzer shows that the segmented TCP is will be reassemble in frame 22.

Frame 15:

Source: 131.247.95.216

Destination: 64.233.161.99

Protocol: TCP

information: TCP Checksum incorrect

From the above information the packet send to the address 64.233.161.99 got the following descriptions:

Transmission Control Protocol, src port: imyx (1143), dst port: http (80), seq: 961, Ack:4512, len:0

source port: imyx (1143)

destination port: http (80)

sequence number: 961 (relative sequence number)

acknowledgment number: 4512 (relative ack number)

header length: 20 bytes

Flags: 0x10 (ACK)

Checksum: 0xc636 [incorrect, should be 0xbc2e (it may cause due to the offload of the TCP checksum on the frame)]

good checksum: False

Bad Checksum: True

SEQ/ACK Analysis

according to the analyzer this frame acknowledge the segment if frame 14. Due to this reason the frame got the checksum error.

The RTT to ACK the segment was:0.000060000 seconds.

Here in Frame 16,17 and 18 following things were happened:

The only difference in these frame is that they just replace the sequence number to each other. i.e. Sequence number of each frame is been changed to other frame number.

For example:

the sequence number if frame 16 is 4512 and the next sequence number is 5942. The sequence number 5942 is indicate the following sequence for the frame 16 while sequence 5942 is the primary sequence number in frame 17. Similarly in frame 17 the primary sequence number is 5942 and the following sequence number is 7372. The sequence number 7372 is the main sequence number for the frame 18. Same thing is happening in the frame 18. The primary sequence number of this frame is 7372 and the following sequence number is 8802, and the acknowledgment for all these frame 16, 17, and 18 is same as 961. source port for every frame 16, 17 and 18 are same to http (80) and similarly the destination port is also same to imyx (1143) to all port 16, 17 and 18.

The checksum of the different frame is different. The following are the checksum for the different frame

frame 16: checksum: 0x6948 which is correct for this frame.

Frame 17: checksum 0xabe7 which is also correct for this frame.

Frame 18: checksum 0xec55 this also shows the correct checksums for this frame.

Flags for all these frame 16, 17 and 18 is same to each others which is 0x10 (ACK)

following are the information of the Frame 16, Frame 17 and Frame 18.

Frame 16: SEQ/ACK analysis.

This frame shows ACK in frame 15 and the time for this segment is 0.0000.44000 seconds. The segmented ACK is will be reassembled PDU in the frame 22, where the TCP segmented data is 1430 bytes.

Frame 17: The segmented packet sent in this frame will be reassembled in the frame 22 by the help of PDU.

Frame 18: In this frame same thing will be applied as in the frame 17.

Here in Frame 19 and 21 shows the same kind of error. Following are the information provide by the frame 19 and frame 21.

What we found in the information of Frame 19 and frame 21 is almost same except the data shown in the Ack, in frame 19 the Ack is 7372 and in frame 21 Ack is 10232. This is the only different found on the information of the frame 19 and 21. Even the packet send by the same address and the destination is also same in for the both the frame 19 and the frame 21.

In frame 20 and 22 following are the information provided:

Transmission Control Protocol, src port: http (80), Dst port: imyx (1143), seq: 8802, Ack: 961, len:1430

next sequence number is 10232

Acknowledgment is similar to the frame 19 and 21 which is 961

header length: 20 bytes

Flags:0x10

checksum is correct in this frame

SEQ/ACK analysis

This is the ack segment which is occur in the frame 19 with the RTT to ACK the segment was: 0.000050000 seconds.

The segmented ack will be reassemble in the frame 22 with the TCP segment data 1430 bytes.

Similarly;

In Frame 22 we cam find the following data:

Transmission Control Protocol, src port: http (80), Dst port: imyx (1143), seq:10232, ack:961, len:184

next sequence number:10416

Acknowledgment number is same to the other frame like 19,20, and 21 which is 961

header height is 20 bytes

flags: 0x18 (PSH, ACK)

checksum: 0x9f21 which is correct for this frame.

The above information of the Frame 13 to 22 shows the different similarity between the frame and the information of those frames. It helps to compare the bad checksums with the correct checksums and the what are the error of the bad checksums.

exercise 1 Question G

The request send by the IP address 131.247.95.216 in frame 11 using TCP protocol fails to reach to the destination address 64.233.161.99. After failing to reach the packet in the IP 64.233.161.99 the IP address 131.247.95.216 sends the packet to the IP address 64.233.161.99 using the HTTP protocol in frame 12. This action is been performed by itself and user has performing no action. In action what we can notice that the IP 131.247.95.216 tries to perform under the secure communication in frame 11 after failing to perform the secure communication in frame 11 it use the alternate method to get success by using HTTP protocol which is the web based communication in frame 12.

exercise 1 question F

Here in Frame 11 packet was send to the address 64.233.161.99 using the TCP protocol. The packet send by the IP 131.247.95.216 was lost while sending to the IP 64.233.161.99. This happen due to the check sum error. Followings are the information about the packet in frame 11:

Frame 11 (54 bytes on wire, 54 bytes capture)
in this frame the frame is marked as false.
Coloring rule name: checksum Errors.
Similarly
Internet protocol
version 4
identification: 0x1053
flags: 0x04
Header checksum: 0x0000 [incorrect, should be 0x2461]
Good: false
bad: true
The above data shows that the packet send by the IP 131.247.95.216 was get lost due to the above condition. The checksum should be 0x2461 but in the packet the checksum is 0x0000 which shows that the packet on this frame is lost.
The information of this frame is mention below
imyx > http [ACK] Seq=493 Ack=1652 win=17520 [TCP CHECKSUM INCORRECT]
This information provides that the packet type is not the correct send by the IP 131.247.95.216 to the address 64.233.161.99, therefore the packet could not be recognize by the destination address.

exercise 1 question e

Here in the frame 9 and 10 the source is same 64.233.161.99 and sends the packet using the different protocols to the same destination 131.247.95.216. In frame 9 the IP 64.233.161.99 sends the packets to the IP 131.247.95.216 using TCP protocol. The information provided on the frame 9 is the segmented TCP protocol was been reassembled using PDU. While in Frame 10 the packet send from the IP 64.233.161.99 to the IP 131.247.95.216 using HTTP. The information provided in frame 10 is the packet is been send on the text/html format using HTTP/1.1 200.

Following are the information from the frame 9

Following are the information from the frame 10

exercise 1 question D

From the question the frame 8 is used to manage the flow control. In this frame IP 64.233.161.99 sends the packet to the IP 131.247.95.216 through TCP to perform the Window update.

exercise 1 question C

The frame 6 and 7 trying to communicate between each other. In frame 6 IP address 131.247.95.216 tries to communicate with the IP address 64.233.161.99 using HTTP protocol. Unfortunately the the packet send by IP 131.247.95.216 could not received by the IP 64.233.161.99, while sending the packet to the 64.233.161.99 by 131.247.95.216 gets the following problems.
Header checksum: 0x0000 [incorrect, should be 0x2276]
good checksum=False
bad checksum = True
source port: imyx (1143)
destination port: http (80)
flags : 0x18 (PSH, ACK)

Similarly in frame 7 the IP 64.233.161.99 sends the reply to the IP 131.247.95.216 using the TCP protocol. Followings are the process of the replying to the IP 131.247.95.216 by IP 64.233.161.99
Header Checksum: 0x075b [correct]
Good: True
Bad : False
Source port: HTTP (80)
Destination port: imyz (1143)
Flags: 0x10 (ACK)

From the above what we can found is that the IP 131.247.95.216 send the packet to the IP 64.233.161.99 which is not correct and the IP 64.233.161.99 sends the reply to the IP address 131.247.95.216 through the TCP and the reply as http > imyx [ACK] seq=1 ACK=493 win=7698 len=0. According to the analyzer the above description in the frame 7 replied to the frame 6 in correct even the request send by the IP 131.247.95.216 to the IP 64.233.161.99 was the wrong packet.

exercise 1 question B

While analyzing the network through network analyzer we found the following happening in the frame 3, 4, and 5.
Frame 3: Source 131.247.95.216 sends the information to the destination address 64.233.161.99 by using the TCP protocol. While sending the request to the destination address from the source address .The color displayed in the frame 3 shows the error in the frame while sending the request from the source 131.247.95.216 to the destination 64.233.161.99. Following is happened in the Frame 3:




Frame 4: In this frame the source is 64.233.161.99 replies the information to the address 131.247.95.216 through the TCP protocol. While replying to the address 131.247.95.216 there is no error while replying the query send by the address 131.247.95.216 on frame 3. Followings are the screen shots of the frame 4 which shows what is happened during this process:

Frame 5: In this frame the source is 131.247.95.216 sends the information to the address 64.233.161.99 through the TCP protocol. While Sending the request to the address 131.247.95.216 there is same error occur as in the Frame 3. Followings are the screen shots of the frame 5 which shows what is happened during this process:

exercise 1 question A

The IP address of the client which initiates the conversation is mention below:

source = 131.247.95.216

destination=131.47.90.200 or 64.233.161.99

protocol= DNS and TCP

Here from the above information we can find the followings

The ip 131.247.95.216 is the source which sends the packets through DNS protocol to the address which IP is 131.47.90.200 to visit the www.google.com

To get the website name www.google.com initially the IP address 131.247.95.216 sends the information to the IP address 131.47.90.200 through DNS protocol. Once the IP address 131.47.90.200 gets the information sends by the IP address 131.247.95.216 then the destination address reply to the message through DNS protocol. The destination address got the two IP address one is 131.47.90.200 and 64.233.161.99, in this case the source address can send the packets in either 131.47.90.200 or 64.233.161.99. If the IP 131.247.95.216 sends the packets through the TCP protocol then the packets will be received by the IP 64.233.161.99 and it reply the packets to the IP 131.247.95.216 through the TCP protocol. The following screen shots shows the DNS query and TCP, src port informations.

Screen shot of DNS

Screen Shot of TCP

The first two packet which is going to contact the identified server are DNS and TCP packets. The network analyzer detect the TCP and HTTP mostly comparing to the DNS protocol. And the most used IP address to contact with the server is 131.247.95.216 and 64.233.161.99. This two IP address the most active during the network capture. But there is another IP address which also active is 131.247.92.200. Followings are the common name and the most Active IP address:

Common Name: HTTP and TCP

IP Address: 131.247.95.216, 64.233.161.99 and 131.247.92.200

Here

131.247.95.216 is the IP address from where the request is send to the 131.247.92.200 IP address to get the required information from the 131.247.92.200. To send the query from the IP address 131.247.95.216 it uses the DNS protocol to the 131.247.92.200, similarly the IP address 131.247.92.200 use the same protocol DNS to reply the query to the 131.247.95.216 address showing the IP address 64.233.161.99. Once the 131.247.95.216 address is directed to the 64.233.161.99 address by the 131.247.92.200 the IP address 131.247.95.216 sends the request to on the 64.233.161.99 address through TCP protocol. Similarly both the IP address 131.247.95.216 and 64.233.161.99 use the HTTP protocol to continue their conversation. Here in the frame 6 the IP address 131.247.95.216 sends the request to the IP address 64.233.161.99 using the HTTP protocol after getting the error on the Frame 5 while sending the request by using the TCP protocol. But the IP address on 64.233.161.99 on Frame 7 reply to the IP address 131.247.95.216 using the TCP protocol .