HTTP 웹 기본지식 - URI와 웹 브라우저 요청 흐름, HTTP 기본

링딩·2022년 7월 15일

HTTP 웹 기초

목록 보기

2/6

chap 2. URI와 웹 브라우저 요청 흐름

1. URI

사실 URI 안에는 URL과 URN 모두 들어간다.
Uniform: 리소스 식별하는 통일된 방식
Resource: 자원, URI 를 식별할 수 있는 모든 것
Identifier: 다른 항목과 구분하는데 필요한 정보

1-1. URL, URN 더 자세히?

URL _location...
- 더 자주 쓰임
- 리소스가 있는 위치를 뜻함
URN _name...
- 리소스에 이름 부여
- 이름은 잘 변하지 x

=> 강사님께서는 URI와 URL을 같은 선상에서 보신다고 하셨다.

1-2. URL 문법 분석

예시.

크게 프로토콜(https)/호스트명(www.google.com) / 포트번호(443) / 패스(/search)/쿼리 파라미터(q=hello&hl=ko) 으로 나뉘어짐.

1. scheme

주로 프로토콜 사용

프로토콜? 어떤 방식으로 자원에 접근할 것인가 하는 약속
(ex http-80 포트, https = 443 포트.. )

포트 생략 가능

2. host

호스트명

도메인 명 or ip 주소

3. PORT

포트

생략 가능

4. path

리소스 경로

구조를 뜻함
ex) /members -> 리소스가 members 아래에 경로임
/members/100 -> members 아래의 100번째? 100번 등 계층 구조에 따라 정보는 달라짐.

5. query

key = value 형태

?로 시작, &으로 이어서 추가 가능함
ex) key1=valueA&keyB=valueB..

query parameter, query string 등으로 불린다.
-> 애초에 key value 형식이 string타입으로 들어가는지라

2. 웹 브라우저의 흐름

과정

1. 도메인과 port를 확인해 세팅 후 웹 브라우저는 HTTP요청 메세지를 생성한다.

HTTP 요청메시지

이런 식으로 메소드의 타입/ 계층 구조 등을 담아 요청을 보냄

2. SOCKET 라이브러리를 통해 TCP/IP에 연결 및 데이터를 전달함.

웹 브라우저로부터 패킷으로 감싸여진 'HTTP 요청 메시지' 곧, 요청 패킷을 받은 서버는 패킷을 벗긴 후 메시지를 확인한다.

응답을 위해 서버는 'HTTP 응답 메시지'를 패킷에 감싸 전송한다(응답 패킷).

웹 브라우저는 응답 패킷을 받아 TCP/IP 패킷을 벗기고 HTML 본문 그대로 브라우저에 렌더링해 화면에 보여준다.

chap 3. HTTP 기본

1. HTTP 개념

우선 HTTP는 뭘까?
그것에 대해선 간단히 정의하고 들어가자
HTTP 프로토콜(The Hypertext Transfer Protocol)은 이름 그대로, hypertext 를 전송하기 위한 프로토콜이다.

hypertext : 인터넷 상에서 서로 연결될 수 있는 형태를 지닌 문서

2. HTTP 알아보기

이젠 HTTP 메시지에 모든 것을 담을 수 있다.

👀 HTTP 메시지에는 모든 것을 전송할 수 있다.

HTML, TEXT
이미지, 음성,영상, 파일
흔히 쓰는 JSON, XML (API)
대부분의 모든 형태들을 데이터 전송이 가능해졌다.

2-1. HTTP의 역사

현재는 HTTP/1.1 을 가장 많이 사용하며 HTTP/2와 3의 경우 성능을 개선한 버전이다.

TCP: HTTP/1.1, HTTP/2

UDP: HTTP/3

2-2. HTTP 특징

클라이언트 서버 구조
무상태 프로토콜(스테이스리스), 비연결성
HTTP 메시지
단순함, 확장 가능

1. 클라이언트 서버 구조

요청(Request)과 응답(Response)의 형태로 이제 클라이언트와 서버가 확실하고 본인의 역할을 가져 명확히 구분되어 있다.

2. 무상태 프로토콜(Stateless)

서버가 클라이언트의 상태를 보존하지 x
장점) 서버 확장성 높음
단점) 클라이언트가 추가 데이터 전송을 해야 함

💬 Stateless(무상태) / Stateful (상태유지)의 차이

[중간에 서버에 문제가 생기면]

Stateless의 경우 상태를 기억(보관)하지 않고, 매번 클라이언트에서 요청을 받아서 응답하기 때문에
다른 서버로 전달하여 응답할 수 있다.
그에 반하여 Stateful의 경우 이에 대처할 수 없다는 단점이 있다.

=> Stateless로 개발을 하면 좋지만...!!

💦💦 Stateless 의 한계도 알아보자

모든 것을 무상태로 설계 할 수 있는 경우도 있고 없는 경우도 있다.
무상태
ex 로그인이 필요 없는 단순한 서비스 소개 화면
상태 유지
ex 로그인
로그인한 사용자의 경우 로그인 했다는 상태를 서버에 유지
-> 일반적으로 브라우저 쿠키와 서버 세션등을 사용해서 상태 유지
결론 : 상태 유지(Stateful)는 최소한만 사용

3. 비 연결성

HTTP는 기본이 연결을 유지하지 않는 모델
일반적으로 초 단위의 이하의 빠른 속도로 응답
1시간 동안 수천명이 서비스를 사용해도 실제 서버에서 동시에 처리하는 요청은 수십개 이하로 매우 작음
예) 웹 브라우저에서 ~~계속 연속해서 검색 버튼을 누르지는 않는다.~~
서버 자원을 매우 효율적으로 사용할 수 있음

=> 물론 한계는 있다. 😥😥

매번 연결을 새로 맺거나 다시 화면의 앞단(html,css, javascript)와 같은 자원을 다시 다운받아야 함...
=> 그래도 지금은 HTTP 지속연결로 문제를 해결했다.

4. HTTP 메시지

4-1. 메시지 구조

4-2. HTTP 요청 메시지

1) GET

HTTP 메서드 _GET, POST, PATCH, DELETE..
(ex GET은 조회)

2) /search?q=hello&hl=ko

요청 대상
절대 경로 = "/" 로 시작.
?query=...

3) HTTP/1.1

HTTP 버전

4-3. HTTP 응답 메시지

1) HTTP/1.1 200 OK

시작라인 및 짧은 상태 코드 설명(OK)
200: 성공,
400 : 클라이언트 요청 오류
500: 서버 내부 오류

2) Content-Type: text/html;charset=UTF-8
Content-Length: 3423

HTTP 전송에 필요한 모든 부가정보
예) 메시지 바디의 내용, 메시지 바디의 크기, 압축, 인증, 요청 클라이언트(브라우저) 정보, 서버 애플리케이션 정보, 캐시 관리 정보...
표준 헤더가 너무 많음
필요시 임의의 헤더 추가 가능

<html>
 <body>...</body>
</html>

메시지 바디
실제 전송할 데이터
HTML 문서, 이미지, 영상, JSON 등등 byte로 표현할 수 있는 모든 데이터 전송 가능

=> HTTP 는 매우 단순하고 확장성도 좋다

링딩

초짜 백엔드 개린이

이전 포스트

HTTP 웹 기본지식 - 인터넷 네트워크

다음 포스트