I've read some similar questions but I think this one has not been done yet. The thing is, once the Server gets the petition to provide a file to the Client, this one sends the info with [ACK] and [PSH,ACK] and does not wait to get a response from Client acknowledging that it has recieved the file properly to send [FIN,ACK]. I don't know if it's supposed to do that but I don't think so.
WireShark analysis
The FIN from the server just says that the server is done sending data. The server can still read data from the client. While not very common this behavior is allowed within the TCP standard. It can for example be achieved by calling shutdown(fd, SHUT_WR) on the server side.
Related
Hey i have a quick question about some ssl stuff.
Is there any way NOT to send acknowledgement (ACK) back to the server after its response?
What am i doing, is testing a friends webapp, written in PHP i suppose, but i don't have a source code, and i think this is more of a general thing. What am i doing is asking a server for some data, handshake happens, i receive data and send ACK that the data were recieved. Then the server "FIN" the connection.. Thats what usually happens, but i'm using Burp proxy to intercept the servers response and noticed that if i drop the response the connection state is on "CLOSE_WAIT" and i don't receive the FIN signal after that, but the server know that i received the data.
So is there any way not to tell the server that i received the data? Basically fake that the data were lost somewhere, but still look at the response? Can Burp Suite do something similar to this or do you know any handy tools that might help? I can provide more info you want.
Thanks a lot!<3
I'm an application developer looking to learn more about the transport layer of my requests that I've been making all these years. I've also been learning more of the backend and am building my own live data service with websockets, which has me curious about how data actually moves around.
As such I've learned about TCP, and I understand how it works, but there's still one term that confuses me-- a "TCP Connection". I have seen it everywhere, and actually there was a thread opened with the exact same question... but as the OP said in the comments, nobody actually answered the question:
TCP vs UDP - What is a TCP connection?
"when we say that there is a connection established between two hosts,
what does that mean? If I could get a magic microscope and inspect the
server or the client, and - a-ha! - find the connection, what would I
be looking at? Some variable allocated by the OS code? Some entry in
some kind of table? How and when does that gets there, and how and
when it is removed from there"
I've been reading to try to figure this out on my own,
Here is a nice resource that details HTTP flow, also mentions "TCP Connection"
https://blog.catchpoint.com/2010/09/17/anatomyhttp/
Here is another thread about HTTP Keep-alive, same "TCP Connection":
HTTP Keep Alive and TCP keep alive
My understanding:
When a client wants data from server, SYN/ACK handshake happens, this "connection" is established, and both parties agree on the starting sequence number, maximum packet size, etc.
as long as this "connection" is still open, client can request/receive data without doing another handshake. TCP Keep-alive sends a heartbeat to keep this "connection" open
1) Somehow a HTTP Header "Keep-alive" also keeps this TCP "connection" open, even though HTTP headers are part of the packet payload and it doesn't seem to make sense that the TCP layer would parse the HTTP headers?
To me it seems like a "connection" between two machines in the literal sense can never be closed, because a client is always free to hit a server with packets (like the first SYN packet, for example)
2) Is a TCP "connection" just the client and server saving the sequence number from the other's IP address? maybe it's just a flag that's saying "hey this client is cool, accept messages from them without a handshake"? So would closing a connection just be wiping that data out from memory?
... both parties agree on the starting sequence number
No, they don't "agree" one a number. Each direction has their own sequence numbering. So the client sends in the SYN to the server the initial sequence number (ISN) for the data from client to server, the server sends in its SYN the ISN for the data from server to client.
Somehow a HTTP Header "Keep-alive" also keeps this TCP "connection" open ...
Not really. With HTTP keep-alive the client just asks a server nicely to not close the connection after the HTTP response was sent so that another HTTP request can be sent using the same TCP connection. The server might decide to follow the clients wish or not.
To me it seems like a "connection" between two machines in the literal sense can never be closed,
Each side can send a packet with a FIN flag to signal that it will no longer send any data. If both sides has send the FIN the the connection is considered close since no one will send anything and thus nothing can be received. If one side decides that it does not want to receive any more data it can send a packet with a RST flag.
Is a TCP "connection" just the client and server saving the sequence number from the other's IP address?
Kind of. Each side saves the current state of the connection, i.e. IP's and ports involved, currently expected sequence number for receiving, current sequence number for sending, outstanding bytes which were not ACKed yet ... If no such state is there (for example one site crashed) then there is no connection.
... maybe it's just a flag that's saying "hey this client is cool, accept messages from them without a handshake"
If a packet got received which fits an existing state then it is considered part of the connection, i.e. it will be processed and the state will be updated.
So would closing a connection just be wiping that data out from memory?
Closing is telling the other that no more data will be send (using FIN) and if both side have done it both can basically remove the state and then there is no connection anymore.
I'm implementing a TCP stack, and have encountered an issue with half-closed connections.
My implementation acts as the server side. A client establishes a connection, then sends some data, and then sends a "FIN" message. The server then acknowledges the data from the client, sends some data of its own, and only then closes its half of the connection (sends "FIN").
The problem is that the client does not acknowledge the data sent by the server on the half-closed connection, nor its final "FIN" message. According to netstat, the client is in state FIN_WAIT2. In an identical scenario in which the server does not send any data, things go smoothly.
The client in question is netcat, so I assume the problem is on my end :)
A screen shot is available here.
The actual PCAP file is available here.
My question is, generally, should I expect ACKS for data sent on a half-closed connection; and, particularly, what am I doing wrong in the example above.
Any help would be much appreciated!
Maybe the server should send ACK=2561 instead of 2562 in FIN/ACK?
FIN-WAIT-2 means it saw the ACK, so the sequence number must be correct, but it also means it didn't see the FIN in the same segment. If the FIN counts as 1 byte maybe the LEN should be 1?
As per title. I've been google'ing extensively and found nothing. I've tried the RFC definition of HTTP/1.1, however it is a quite cubersome document. Does the server send anything? (now is a good time to mention that I want to use persistant connections?)
With HTTP/1.1 persistent connections, the connection may be kept open after a request, typically for a few seconds. Once some time has passed, the TCP connection is simply closed. No messages or anything are sent. None are needed.
You can easily see this yourself if you fire up a packet sniffer, like Wireshark.
I need a way to detect a missing response to a long running HTTP POST request. This problem arises when the network infrastructure (firewalls, proxies, unplugged cables, etc.) drops the response packets. The server may detect this failure, but the client cannot send additional bytes after the POST to probe the state of the TCP connection. The failure may be limited to a single TCP connection. For example I may be able to subsequently open a new TCP connection to the server.
I'm looking for a solution that still uses HTTP POST and does not change the duration of the server side processing.
Some solutions that I can think of are:
Provide a side channel interface to retrieve request & response history. If the history lists the response as having been send (presumably resulting in a TCP error) but I have not yet received it within a reasonable time I can generate a local error.
Use an X header to request that the server deliver "spurious" 100 Continue provisional responses on a regular interval. If I fail to see an expected 100 Continue or a non-provisional response I can generate a local error.
Is there a state of the art solution for this problem?
It sounds to me like you are using Soap for something that would be much better done using a stateful connection, or a server side push technology.