HTTP
먼저, 웹 페이지는 많은 오브젝트들을 포함하고 있다.
HTML file, JPEG image, Java applet,, 등등
HTTP
= Hypertext transfer protocol
🔥 웹 어플리케이션 레이어 프로토콜이다
- 웹 클라이언트 : HTTP 프로토콜을 사용해서 request를 요청하고, 받고, 보여준다.
- 웹 서버 : HTTP 프로토콜을 사용해서 요청에 맞는 응답을 보내준다.
✔️ 이 응답에 해당하는 게 HTML file이나,, 오브젝트들 !
✅ HTTP의 특징
- TCP를 사용한다
- stateless임
서버에서 이전 클라이언트의 리퀘스트 정보를 기록하지 않음. 즉 어떤 클라이언트가 요청했는지 저장하지 않는 것
= state까지 저장할 여력이 없고, 저장할 필요가 없는 경우가 많기 때문에
그렇지만 !!!! 예외도 있음 = 쿠키 🍪
✅ HTTP의 종류
🚀 RTT = Round-trip time
패킷이 클라이언트에서 서버로 갔다가 다시 돌아오는 시간
TCP connection을 맺으려면 1RTT가 필요함
✔️ Non-persistent HTTP : TCP connection을 request할 때마다 함
= TCP 연결 한번에 최대 하나의 객체를 전송할 수 있다.
-
순서 :
TCP 커넥션을 서버한테 initiate ➡️ 서버가 기다리고 있다가 accept ➡️ 클라이언트가 리퀘스트 메세지를 보냄 ➡️ 서버가 response 메세지 보냄 ➡️ 서버가 tcp 커넥션 끊음 ➡️ 클라이언트가 response를 받아서 html을 받고 열었음 참조해야할 이미지나 오브젝트들이 10개임 ➡️ 이 방법 그대로 10번 반복 -
HTTP Response time : 2RTT * 객체의 수 + file transmission time
왜 ❓❓❓ : 매번 TCP 커넥션을 계속 해줘야 하기 때문에 !!
✔️ Persistent HTTP : TCP connection을 첫 request할 때만 함
= TCP 연결 한번에 여러개의 객체를 전송할 수 있다.
- 서버가 response를 보내고도 커넥션을 남겨놓는 것. 그리고 일정한 시간이 지나고 나면 커넥션 close (= timeout)
- HTTP Response time : 1RTT + 1RTT * 객체의 수 + file transmission time
- 문제점 : 서버가 계속 TCP connection을 유지하고 있어야 하기 때문에 서버가 할 일이 늘어남. 하지만 TCP connection을 그때 그때 하는 것보다 낫게 때문에 현대에서는 persistent HTTP 사용함.
📎 이 HTTP의 종류는 request message와 response time 헤더에 지정해서 보내줍니다~
쿠키 🍪
state를 보관해두는 것 !
✔️ 어디에 사용?
- authorization
- recommendations
- 장바구니
등등
Web
웹 캐시 (프록시 서버)
✔️ 목적 : 원래의 서버에 들리지 않고도 클라이언트의 리퀘스트에 응답할 수 있게 하기
✔️ 특징 :
- 프록시 서버와 클라이언트는 같은 ISP내에 존재합니다.
- 브라우저가 모든 HTTP 리퀘스트를 프록시 서버에게 보낸다
➡️ 응답 가능 : 프록시 서버에서 응답
➡️ 응답 불가능 : 원래 서버한테 응답 요청
✔️ 장점과 단점 :
- 직접 서버에 가는 것보다 프록시 서버를 거치는 것이 시간이 더 걸림
👍🏻 하지만, 프록시 서버는 클라이언트와 같은 ISP내에 있기 때문에 시간 차이가 극도로 작고, 서버 입장에서는 로드가 줄어들어서 이득임 - 프록시와 원래 서버의 동기화 문제를 해결해야 함
📎 Conditional GET과 같은 방법을 사용 - 프록시의 cache hit rate를 높여야 함
✅ 웹 캐시와 프록시 서버
프록시 서버가 캐싱 기능도 하는 것.
E-Mail은 asynchronus communication입니다 ~~
- Asynchronus는 사용자가 받을 준비가 되었든, 안되었든 일단 보내는 사람은 보내고 보고 받고 싶은 사람은 받고 싶을 때 받을 수 있게 하는 방식입니다.
- HTTP 는 synchronus입니다. 서버와 클라이언트가 바로바로 커뮤니케이션 해야 함.
☝🏻 보내고자 하는 쪽의 UA가 자신의 메일 서버의 메세지 큐 에 메일을 넣어 둔다
✌🏻 보내고자 하는 쪽의 SMTP client가 server와 TCP 커넥션을 맺는다
🤟🏻 SMTP client가 server 측의 메일박스에 보낼 메세지를 저장한다.
🖖🏻 메일박스에 저장해두고 있다가, 받아야하는 쪽이 읽을 상황이 되면 UA가 메일 서버에서 메일을 불러와서 보여줌
✅ E-Mail component
✔️ User agents (클라이언트 프로그램)
- 사용자가 읽고, 답장하고, 보내고 하는 그런 것들을 가능하게 함
- MS Outlook, iPhone mail client 등..
✔️ 메일 서버
- 메세지 큐 : 보낼 메세지를 저장하는 곳
- 메일 박스 : 받은 메세지를 저장하는 곳
- 메일 서버가 SMTP를 사용해서 메세지를 주고 받음 !
✔️ SMTP(Simple Mail Transfer Protocol) = Application layer protocol
- 받는 쪽에게 보내는 쪽한테 바로 ! 보낸다
- 메일이 분실되면 안되기 때문에 TCP를 사용
✅ HTTP vs SMTP
✔️ HTTP : 웹 서버에서 웹 클라이언트로 파일을 전송하는 프로토콜
- pull protocol : HTTP 클라이언트가 서버로부터 정보를 당겨옴
- 받고 싶은 쪽이 TCP 커넥션을 연결합니다
✔️ SMTP : 메일 서버에서 메일 서버로 파일을 전송하는 프로토콜
- push protocol : 보내는 메일 서버가 받는 메일 서버한테 정보를 밀어줌
- 보내고 싶은 쪽이 TCP 커넥션을 연결합니다
✅ POP3, IMAP, Web-mail
🌀 메일 서버에서 메일을 가져올 때는 SMTP를 사용하지 않습니다 🌀
- 왜 ? SMTP는 심플하기 때문에 메세지큐에 저장하는 것 까지만 가능합니다. 수신자는 메세지를 컴퓨터, 핸드폰, 태블릿 등에서 모두 확인할 수 있기 때문에 SMTP는 서버 보관함까지만 작용하고 수신자는 밑의 3가지 방법으로 직접 메일을 가져옵니다~
✔️ POP3
- POP는 전자 메일 서비스에 문의하고 새 메시지를 모두 다운로드하여 작동합니다.
- 다운로드되면 전자 메일 서비스에서 삭제됩니다. 즉, 전자 메일을 다운로드한 후 동일한 컴퓨터 를 사용하여만 액세스할 수 있습니다.
- 스토리지용량에 제한있는 경우 유리.
✔️ IMAP
- POP과는 달리 중앙 서버에서 동기화가 이뤄지기 때문에 모든 장치에서 동일한 이메일 폴더를 확인할 수 있다. = 여러 다른 장치에서 전자 메일을 확인해야 하는 경우 권장되는 방법
- IMAP를 사용하여 전자 메일 메시지를 읽을 때 실제로 컴퓨터에 다운로드하거나 저장하지 않습니다. 대신 전자 메일 서비스에서 읽습니다. 따라서 휴대폰, 컴퓨터, 친구의 컴퓨터 등 전 세계 어디서나 다양한 장치에서 전자 메일을 확인할 수 있습니다.
- 메일이 서버에 저장되어있기 때문에 로컬pc에 문제가 생겨도 이메일에는 아무 영향을 미치지 않는다.
- 클릭했을 때 메세지만 다운받아오고 첨부파일은 다운 받아오지 않기 때문에 POP보다 빠르게 읽어올 수 있음
✔️ Web-mail
- UA는 웹 브라우저이고 메일 박스와 HTTP를 사용해서 통신합니다.
- 다른 메일 서버로 메일을 보낼 때는 SMTP를 사용합니다
- Gmail, Naver mail 등이 해당
