I'm trying to send the same file from the server to client and vice versa (across internet, not in local network where it works as expected).
# server --> client
client: ./srt-file-transmit srt://[HOST]:[PORT] file:///path/to/file -loglevel:debug
server: ./srt-file-transmit file:///path/to/file srt://:[PORT]?mode=listener -loglevel:debug
# client --> server
client: ./srt-file-transmit file:///path/to/file srt://[HOST]:[PORT] -loglevel:debug
server: ./srt-file-transmit srt://:[PORT]?mode=listener file:///path/to/file -loglevel:debug
In the server --> client scenario, my speed is peaking at around 200KiB/s.
On the other hand, in the client --> server scenario, I can get easily to around 30MiB/s.
With UDP, both ways are approximately the same (30 MiB/s).
What could be the issue in the server --> client scenario? Why it might be so slow?
Related
I'm implementing HTTP over TLS proxy server (sni-proxy) that make two socket connection:
Client to ProxyServer
ProxyServer to TargetServer
and transfer data between Client and TargetServer(TargetServer detected using server_name extension in ClientHello)
The problem is that the client doesn't close the connection after the response has been received and the proxy server waits for data to transfer and uses resources when the request has been done.
What is the best practice for implementing this project?
The client behavior is perfectly normal - HTTP keep alive inside the TLS connection or maybe even a Websocket connection. Given that the proxy does transparent forwarding of the encrypted traffic it is not possible to look at the HTTP traffic in order to determine exactly when the connection can be closed. A good approach is therefore to keep the connection open as long as the resources allow this and on resource shortage close the connections which were idle (no traffic) the longest time.
Client connects to server and sends request with keep-alive header. Server response also contains keep-alive header.
Now client loses power. Is there any mechanism (like ping) in TCP or HTTP stack, which tells server, that client is not there (other than timeout)?
Now client loses power. Is there any mechanism (like ping) in TCP or HTTP stack, which tells server, that client is not there (other than timeout)?
There is TCP keep alive which is specifically designed to detect lost connectivity.
HTTP follows the request-response model, i.e. for every request from a client there will be a response from the server.
Does there exist any protocol that follows only request model (there will be only requests from client)?
I know SMTP. Can I consider SMTP as request only model because we are sending the mail but not receiving any response from server?
If there exists any other such protocol, please explain about it. I googled it but didn't find any answer related to my specific query.
Can I consider SMTP as request only model because we are sending the mail but not receiving any response from server?
No, because for every command the client sends to the SMTP server, the client gets a response. SMTP is a lot more chattier than HTTP. Just to send a single email, an SMTP server and a client communicate with each other at least 5 times.
This is how SMTP works:
Client: EHLO yourdomain.com
Server: 250 smtp.gmail.com
Client: MAIL FROM: you#yourdomain.com
Server: 250 Ok
Client: RCPT TO: someone#gmail.com
Server: 250 Ok
Client: DATA
Server: 354 Start mail input; end with <CRLF>.<CRLF>
Client: Hey how are you?
Client: .
Server: 250 Ok
Client: QUIT
Server: 221 smtp.gmail.com Closing connection. Goodbye!
As you can see, this is also a request-response protocol.
But the Wikipedia page that you linked says that SMTP is a one-way protocol, which is wrong.
Does there exist any protocol that follows only request model (there will be only requests from client)?
Most protocols are there for exchanging data, that is why they follow the request-response model. The client wants to see a page, so he requests it from the server and then the server sends the page in response. The data is being exchanged between the server and the client.
But if you want you can write a protocol which is one way only.
I'm building a HTTP client(for embedded devices) and I was wondering,
If I receive a HTTP 3xx response, and in the location header I get a hostname different from the one I had in the request. Should I disconnect the TCP connection and reconnect to the new host, or I just need to send a new request with a new host header and keep the old TCP connection alive.
Thank you
It doesn't make sense to reuse the original TCP connection if you're being redirected elsewhere. If my webserver only hosts example.com and I redirect you to elsewhere.net, my webserver will probably not respond to a request for elsewhere.net.
Worse, this also potentially sets you up for a great man-in-the-middle attack if my server redirects you to http://bank.com and you reuse the same TCP connection when sending a request to bank.com. My server can maliciously respond to requests with Host: bank.com, which isn't something you want to happen.
You can't assume the original connection can be reused unless the redirect is to the same same host with the same protocol.
Persistent HTTP connections are a little tricky with the number of client/server combinations. You can avoid the complexity by just wasting time closing and re-establishing each connection:
If you're implementing a HTTP/1.0 client, Connection: keep-alive isn't something you have to implement. Compliant servers should just close the connection after every request if you don't negotiate that you support persistent connections.
If you're implementing a HTTP/1.1 client and don't want to persist the connection, just send Connection: close with your request and a HTTP/1.1 server should close the connection.
When a server sent a keep-alive header to a client
Does it mean that every requests of this client ip will be benefited?
Does it mean that every requests of this client ip plus session will be benefited?
Put it into a situation.
After I browse a website and the server sent keep-alive to me. I open another browser and go to the same website. Will my second request connect without handshake?
I read the documentation but I could not find out the target. Please help me.
In HTTP 1.0, if both the client and server support keep alive then the connection will be persisted and multiple requests can use the same connection without handshaking each time, benefitting the session by slightly reducing request/response time.
In HTTP 1.1, connections are keep alive by default so this is the expected behaviour.
This happens within the session - another browser window would constitute another session, so there would be no connection sharing and therefore no benefit.