Don't roll your own HTTP server
•Als PPTX, PDF herunterladen•
0 gefällt mir•267 views
This is a session given by Joel W. Kall at Nordic APIs 2016 Platform Summit on October 25th, in Stockholm Sweden. Description: A lot of of today’s APIs are available using HTTP, so it’s no surprise that there are many options available for the software that actually handles the requests. There are giants like Microsoft and Apache, and there are small, modular packages from smaller vendors and independent developers. But if you only need 1% of the features, isn’t it tempting to just write your own HTTP parser? We did, and we wish we didn’t. And now we’ll tell you all about it so you won’t make the same mistakes we did.
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (19)
Ähnlich wie Don't roll your own HTTP server
Ähnlich wie Don't roll your own HTTP server (20)
Mehr von Nordic APIs
Mehr von Nordic APIs (20)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
Don't roll your own HTTP server
- 1. DON’T ROLL YOUR OWN HTTP SERVER JOEL W KALL, CHIEF CCO OFFICER @ LOOP54
- 2. Loop54 • On-site e-commerce search engine • SaaS • Relevant search results • Machine learning
- 3. In the beginning • Small scale prototype • Nothing fancy – just accept requests • No configuration
- 4. HTTP request-response sample POST /path HTTP/1.1 Content-Type: application/json Content-Length: 28 { “key”:”value” } HTTP/1.1 200 OK Content-Type: application/json Content-Length: 31 { "anotherkey":"andavalue" }
- 5. HOLD MY BEER HOW HARD CAN IT BE?
- 12. KEEP-ALIVE & PIPELINING THE NAIL IN THE COFFIN
- 13. Kestrel to the resqueue • Part of ASP.NET Core, embeddable • Cross-platform • 5% faster, 15% less memory • Full HTTP support • Probably more secure
- 14. DON’T DO IT! BUT IF YOU DO, READ UP BEFOREHAND
Hinweis der Redaktion
- co-founder Chief CCO Officer recursive other co-founder Mike mathematician poster boy don't roll
- about Loop54 API integrating smart on-site search ecommerce machine learning relevant synonyms contextual information automatically
- first prototype great API accept HTTP requests and respond start testing live code configuration HTTP features available servers expensive complex to set up both researching
- simple HTTP sample request headers data similar response text based simple to parse
- how hard can it be Hold my beer! might expect immediately headaches list
- 1 Encoding decode the bytes TCP stream characters headers easy ASCII body Content-Type header still need to be smart UTF-16 Little endian or big endian different order Byte-order-mark sometimes it doesnt scan the text figure out ANSI code pages looked this up beforehand add that in What next
- 3 queue not 3 lines of code need configuration threads busy? queue connections drop packets high loads each request new connection 3 second response time ok add queue
- 2. Content-Length can't assume body single packet long body keep reading How know? Content-Length read header read data didn't have logic read once fine in testing production longer requests triggered errors add code what else
- 4 Nagling heard of problem in TCP too many packets congested ack delayed re-transmits more congestion spirals out of control unusably slow overhead small packets bad TM combat this John Nagle algorithm buffers packets one big packet good but x00ms disable client server read up just a line of code or two. We're done, right?
- 5 100 Continue some clients no data first request instead without data header "Expect" permission polite clients asking for permission also means add support 100 Continue stupid well-mannered computers
- 6 Versioning ran through different versions hard-coded API implementations API versions properly different routes We didn't, no route support stuck with a mess clean up now
- 7 Keep alive ultimate nail in the coffin realized keep alive. lost packet wait a while new connection 3 seconds, old connection smarter, match latency, faster each request new connection always slow HTTP feature keep alive client server negotiate hard to implement pool the connections match with threads explicit close timeout Maybe we should have read up on this beforehand.
- Kestrel web server Part of ASP.NET Core, embeddable Cross-platform 5% faster, 15% less memory Full HTTP support Probably more secure
- ultimate advice to anyone building a new HTTP-based API and who feels tempted to just roll your own super-simple server. Dont do it! And if you do - read up on it beforehand and I'm sure the temptation will go away.