일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | |||||
3 | 4 | 5 | 6 | 7 | 8 | 9 |
10 | 11 | 12 | 13 | 14 | 15 | 16 |
17 | 18 | 19 | 20 | 21 | 22 | 23 |
24 | 25 | 26 | 27 | 28 | 29 | 30 |
- leetcode
- 프로그래머스
- gold5
- Kakao
- glod4
- mysql
- jpa
- LCS
- AWS
- 9252
- CSS
- 구현
- java
- glod5
- error
- leetcode 69
- LEVEL2
- siver3
- HTML
- 개념
- 배포
- 오류
- LEVEL1
- Gold4
- spring
- Thymeleaf
- PYTHON
- 백엔드
- gold2
- 백준
- Today
- Total
이 험난한 세상에서어어~
섹션 2, 3 본문
들어가기 전에
이 글을 김영한 님의 '모든 개발자를 위한 HTTP 웹 기본 지식'을 기반으로 하고 있습니다.
https://www.inflearn.com/course/http-%EC%9B%B9-%EB%84%A4%ED%8A%B8%EC%9B%8C%ED%81%AC/dashboard
섹션 2
URI
인터넷에 접속하면 제일 상단에 쓰인 주소를 심심치 않게 볼 수 있다.
https://www.inflearn.com/course/http-웹 네트워크/dashboard
'모든 개발자를 위한 HTTP 웹 기본 지식'의 URI
이런 것들을 통합 자원 식별자 즉, URI로 부르는데 말 그대로 인터넷에 있는 자원들을 나타내는 주소라고 할 수 있다.
URI에는 URL과 URN이 있다. URL은 Uniform Resource locator로 자원의 위치를 표현한 것이고 URN은 Uniform Resource name으로 자원의 이름을 표현한 것이다.
저 둘 중 URL을 보편적으로 이용하는데, 그 이유는 일단 자원의 위치는 바뀔 수 있을 뿐더러 이름보다는 위치를 표시하기가 쉽기 때문이다.
그렇다면 URL이 어떻게 구성되어 있는지 알아보자.
프로토콜://유저정보(거의 사용하지 않음)+호스트 명(도메인 혹은 IP 주소) + 포트(생략 가능)/path?쿼리
- 일단 제일 먼저 http나 https와 같은 프로토콜이 오게 된다.
- 그 다음 유저 정보와 호스트 명 포트 번호가 오게 되는데, 유저 정보는 거의 사용하지 않고 포트 번호는 생략이 가능하다. 실제로 위의 인프런의 URL을 보면 도메인 명인 www.inflearn.com 만 나오는 것을 확인할 수 있다.
- 다음에는 path인데 해당 자원이 어떤 위치에 있는지 계층적 구조로 나타나게 된다. 위의 링크를 예시로 들자면 '모든 개발자를 위한 HTTP 웹 기본 지식'은 course 아래에 존재하는 것을 알 수 있다.
- 마지막으로 쿼리인데, 이는 내가 찾으려는 정보의 value가 들어가 있다. 예를 들어 인프런에서 김영한을 검색했을 경우 쿼리 부분에 's=김영한'이 추가된 것을 알 수 있다. 참고로 쿼리는 물음표 뒤에 들어간다.
웹 브라우저 요청 흐름
그렇다면 URL을 가지고 어떻게 웹 브라우저가 정보를 요청하고 또 가지고 오는 것일까?
이를 천천히 살펴보자
1. 일단 url을 가지고 웹 브라우저는 도메인 명을 가지고 DNS 서버에 가서 IP를 조회한다. 그리고 생략된 PORT도 찾아 온다.
2. 1에서 찾은 정보를 가지고 HTTP 요청 메시지를 생성한다.
3. 이 HTTP 요청 메시지는 소켓 라이브러리로 넘어가고, 소켓 라이브러리에서는 TCP와 IP를 연결하게 된다. 여기서 연결이란 의미는 전 글에서 설명한 3 way handshake와 같은 것이다. 그리고 데이터를 TCP와 IP에 넘긴다.
4. HTTP 메시지를 TCP/IP 패킷을 생성해 감싼 다음 LAN에 넘긴다.
5. LAN에서 Ethernet frame을 씌운 다음 서버에 전달하는 것이다.
6. 그러면 요청 패킷을 받은 서버거 응답 패킷을 웹 브라우저에게 돌려주고 웹 브라우저는 해당 응답 메시지를 읽으면 끝난다.
섹션 3
HTTP의 특징
HTTP의 특징은 무엇이 있을까.
HTTP는 일단 클라이언트 서버 구조로 클라이언트가 요청을 보내면 서버가 그에 대한 답을 주는 방식이다. 그리고 무상태 프로토콜이라고 해서 서버가 클라이언트의 상태를 유지하지 않는다. 이 때문에 서버가 바뀌어도 문제가 없도록 클라이언트는 자신의 상태를 계속해서 갱신하여 가지고 있어야 한다. 장점으로는 서버가 중간에 바뀌어도 문제가 없어 서버의 무한 증가가 가능하지만, 계속해서 상태 유지를 해줘야 경우에는 사용할 수 없다는 단점이 있다. 그러나 무상태 프로토콜을 최대한 사용하는 것이 좋다.
또한 HTTP는 비 연결성이라고 해서 서버는 클라이언트와의 통신이 끝나면 연결을 끊어버린다. 이는 서버의 자원 소모를 줄일 수 있어 빠른 속도의 응답이 가능하다는 장점이 있다. 그러나 계속해서 연결을 새로 맺어줘야 하기 때문에 시간이 오래 걸린다는 단점이 있다. 이를 보완하기 위해 특정한 시간 동안은 통신이 끝나도 클라이언트와 서버의 관계를 유지하는 방법이 있다. 이러한 방법은 HTTP 지속 연결이라고 한다.
HTTP 메시지
HTTP 메시지는 시작 라인, 헤더, 공백 라인, 메시지 바디가 있다.
시작 라인의 경우 요청 메시지와 응답 메시지가 다르다. 요청 메시지의 시작 라인에는 HTTP 메서드와 요청 대상, HTTP 버전이 있다. HTTP 메서드는 GET이나 POST와 같은 행위를 의미하며 요청 대상은 아까 URL에서 봤던 경로와 쿼리를 의미한다. 응답 메시지는 HTTP의 버전과 응답이 잘 됐는지를 의미하는 HTTP 상태코드가 들어가 있다.
HTTP 헤더에는 부가 정보가 들어가 있다.
HTTP 바디에는 실제 전송할 데이터가 들어가 있는데, 예를 들면 HTML이나 이미지, 영상 같은 것들이다.
'이론 > http' 카테고리의 다른 글
섹션 5, HTTP 상태 코드 (0) | 2023.07.19 |
---|---|
섹션 4, HTTP 메서드 (0) | 2023.07.08 |
1. 네트워크 (0) | 2023.07.06 |