HTTP 웹 기본 지식

ID

26

status

Public

menu

Backend

submenu

tags

HTTP

summary

thumbnail

date

Apr 20, 2024

1. 인터넷 네트워크

1-1. 인터넷 통신

1-2. IP(인터넷 프로토콜)

• IP
• 지정한 IP 주소에 데이터 전달
• 패킷(Packet)이라는 통신 단위로 데이터 전달



• IP 프로토콜의 한계
• 비연결성: 패킷을 받을 대상이 없거나 서비스 불능 상태여도 패킷 전송
• 비신뢰성: 중간에 패킷이 사라질 가능성 O, 순서 보장 X
• 프로그램 구분: 같은 IP를 사용하는 서버에서 통신하는 애플리케이션이 둘 이상일 수 있음
• 이와 같은 한계로 추가적인 정보 필요(tcp와 같은 프로토콜)
 

1-3. TCP, UDP

• 4계층: 애플리케이션 계층(Application Layer)

• 3계층: 전송 계층(Transport Layer)

• 2계층: 인터넷 계층(Internet Layer)

• 1계층: 네트워크 인터페이스 계층(Network Access Layer or Network Interface Layer)

• 앞서 말했듯이 IP패킷 만으로 데이터를 전달하기에는 한계가 있기 때문에, tcp를 추가한다

• TCP(전송 제어 프로토콜, Transmission Control Protocol)
• 연결 지향 - TCP 3 way handshake(가상 연결)
• 데이터 전달 보증
• 순서 보장
• 신뢰할 수 있는 프로토콜
• 현재는 대부분 TCP 사용
 

1. 3 way handshake
• syn, syn+ack, ack를 통해 연결을 함 → 이로 인해 IP 프로토콜의 비연결성 문제를 해결



 

2. 데이터 전달 보증 & 순서 보장
• 데이터를 수신하면 잘 받았다는 응답을 함

• 패킷 순서가 잘못 왔다면 패킷을 다시 요청함

→ 이로 인해 IP 프로토콜의 비신뢰성 문제를 해결
 

3. 프로그램 구분
• “1-4”에서 설명(feat. PORT)

• 연결 지향 X, 즉 3-way-handshake를 하지 않음

• 데이터 전달 보증 X

• 순서 보장 X

• 단순하고 빠름

• IP와 거의 같지만 + PORT + 체크섬 정도만 추가

• 애플리케이션에서 추가 작업 필요

1-4 PORT

• 0 ~ 65535 할당 가능

• 0 ~ 1023: 잘 알려진 포트, 사용하지 않는 것이 좋음
• FTP: 20, 21
• TELNET: 23
• HTTP: 80
• HTTPS: 443

1-5. DNS

• 도메인 명을 IP 주소로 변환

2. uri 웹 브라우저

2.1 URI(Uniform Resource Identifier)

• Uniform: 리소스 식별하는 통일된 방식

• Resource: 자원, URI로 식별할 수 있는 모든 것(제한 없음)

• Identifier: 다른 항목과 구분하는데 필요한 정보

• Uniform Resource Locator

• Locator: 리소스가 있는 위치를 지정

• Uniform Resource Name

• Name: 리소스에 이름을 부여

• 위치는 변할 수 있지만 이름을 변하지 않는다
• ex) urn: isbn - 8960777731
• 하지만 urn 만으로 실제 리소스를 찾을 수 있는 방법이 보편화 되지 않음

• 따라서 uri를 url과 같은 의미로 생각하면 됨

scheme://[userinfo@]host[:port][/path][?query][#fragment]

• 프로토콜
• 어떤 방식으로 자원에 접근할 것인가 하는 약속 규칙
• “절차를 포함한 통신 규약”
• http, https, ftp 등이 있다
• http는 80 포트, https는 443 포트 → 포트는 생략가능
• https는 http에 보안 추가(HTTP Secure)

• [userinfo@]
• URL에 사용자 정보를 포함해서 인증
• 거의 사용하지 않음

• host
• 호스트명
• 도메인명 또는 IP 주소를 직접 사용 가능

• port
• 접속 포트
• 일반적으로 생략, 생략시 http는 80, https는 443

• path
• 리소스 경로
• 계층적 구조

• query
• key=value 형태
• ?로 시작, &로 추가 가능
• 쿼리 파라미터, 쿼리 스트링으로 불림

• fragment
• html 내부 북마크 등에 사용
• 서버에 전송하는 정보 아님

2.2 웹 브라우저 요청 흐름

1. DNS 조회를 해 IP 주소를 확인

2. HTTP 요청 메시지 생성

3. 패킷 생성

4. http 메시지 전송

5. 응답

6. 웹 브라우저에서 전달 받은 데이터 처리

3. http

• HTTP/0.9 1991년 : GET 메서드만 지원, HTTP 헤더 X

• HTTP/1.0 1996년 : 메서드, 헤더 추가

• HTTP/1.1 1997년 : 가장 많이 사용, 우리에게 가장 중요한 버전
• RFC2068(1997) → RFC2616(1999) → RFC7230~7235(2014)

• HTTP/2 2015년 : 성능 개선

• HTTP/3 진행중 : TCP 대신에 UDP 사용, 성능 개선
• TCP : HTTP/1.1, HTTP/2
• UDP : HTTP/3
• 현재는 HTTP/1.1을 주로 사용하지만, HTTP/2, HTTP/3 도 점점 증가하고 있다

HTTP가 무엇인지 알아봤으니 이제 http의 특징에 대해서 알아보자

• 클라이언트 서버 구조

• 무상태 프로토콜(stateless)

• 비연결성(connectionless)

• HTTP 메시지

• 단순함, 확장 가능

3.1 클라이언트 서버 구조

• 요청(request) 응답(response) 구조

• 클라이언트는 서버에 요청을 보내고 응답을 대기

• 서버는 요청에 대한 결과를 만들어 응답

3.2 무상태 프로토콜(stateless)

• 서버가 클라이언트의 상태를 보존하지 않음

• 장점: 서버 확장성 높음 → 스케일 아웃

• 단점: 클라이언트가 추가 데이터를 전송해야 함

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

3.3 비연결성(connectionless)

• http는 기본이 연결을 유지하지 않는 모델

• 일반적으로 초 단위의 이하의 빠른 속도로 응답

• 동시 요청은 가능성이 매우 작음(웹 브라우저에서 계속 연속해서 검색 버튼을 누르지 않는다)

• 서버 자원을 매우 효율적으로 사용 가능

• 단점
• TCP/IP 연결을 새로 계속 맺어야 함 → 3 way handshake 시간 추가
• 매번 요청 시 html 뿐만 아니라 css, js, 추가 이미지 등 수 많은 자원이 함께 다운로드
• 지금은 HTTP 지속 연결(Persistent Connections)로 문제 해결





• HTTP/2, HTTP/3에서 더 많은 최적화

3.4 HTTP 메시지

HTTP 요청 메시지

 

 

• 시작 라인
• request-line / status-line
• request-line : method + request-target + HTTP-version

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

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

HTTP 응답 메시지

 

• 시작 라인
• request-line / status-line
• status-line : HTTP-version + status-code + reason-phrase

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

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

 

4. http 메서드

4.1 http 메서드 종류

• 주요 메서드
• GET
• POST
• PUT
• PATCH
• DELETE

• 기타 메서드
• HEAD
• OPTIONS
• CONNECT
• TRACE

GET

• 리소스 조회

• 서버에 전달하고 싶은 데이터는 query(쿼리 파라미터/스트링)를 통해서 전달

• 메세지 바디를 사용해서 데이터를 전달할 수 있지만, 지원하지 않는 곳이 많아서 권장하지 않음

POST

• 새 리소스 생성(등록)
• 서버가 아직 식별하지 않은 새 리소스 생성

• 요청 데이터 처리
• 메세지 바디를 통해 서버로 요청 데이터 전달
• 서버는 요청 데이터를 처리
• 메시지 바디를 통해 들어온 데이터를 처리하는 모든 기능을 수행
• 주로 전달된 데이터로 신규 리소스 등록, 프로세스 처리에 사용

• 다른 메서드로 처리하기 애매한 경우
• JSON으로 조회 데이터를 넘겨야 하는데, GET 메서드를 사용하기 어려운 경우
• 애매하면 POST

PUT

• 리소스를 대체(덮어쓰기)

• 클라이언트(중요!)가 리소스를 식별
• 클라이언트가 리소스 위치를 알고 URI 지정
• POST와 차이점
• 아래 사진처럼 클라이언트가 리소스를 다 알고 있어야 한다

PATCH

• PUT과 달리 리소스를 부분 변경한다

DELETE

• 리소스 제거

4.2 http 메서드 속성

• 안전(Safe Methods)
• 호출해도 리소스를 변경하지 않는다

• 멱등(Idempotent Methods)
• 한 번 호출하든 100번 호출하든 결과가 똑같다
• GET, PUT, DELETE는 멱등 메서드이지만, POST는 멱등 메서드가 아니다!

• 캐시가능(Cacheable Methods)
• 응답 결과 리소를 캐시해서 사용해도 되는가?
• GET, HEAD, POST, PATCH 캐시가능
• 실제로는 GET, HEAD 정도만 캐시로 사용
• POST, PATCH는 본문 내용까지 캐시 키로 고려해야 하는데, 구현이 쉽지 않음
 
 
 

5. http 메서드 활용

5.1 클라이언트에서 서버로 데이터 전송

1. 쿼리 파라미터를 통한 데이터 전송 방식은 주로 GET을 사용해 정렬 필터(검색어)를 전송할 때 많이 사용한다

2. 메시지 바디를 통한 데이터 전송 방식은 주로 POST, PUT, PATCH을 사용해 회원가입, 상품 주문, 리소스 등록, 리소스 변경에 많이 사용된다

1. 정적 데이터 조회
• 이미지, 정적 텍스트 문서

2. 동적 데이터 조회
• 주로 검색, 게시판 목록에서 정렬 필터(검색어)

3. HTML Form을 통한 데이터 전송
• 회원 가입, 상품 주문, 데이터 변경

4. HTTP API를 통한 데이터 전송
• 회원 가입, 상품 주문, 데이터 변경
• 서버 to 서버, 앱 클라이언트, 웹 클라이언트(Ajax)

5.2 HTTP API 설계 예시

6. http status

• 종류
• 1xx (Informational) : 요청이 수신되어 처리중
• 2xx (Successful) : 요청 정상 처리
• 3xx (Redirection) : 요청을 완료하면 추가 행동이 필요
• 4xx (Client Error) : 클라이언트 오류
• 5xx (Server Error) : 서버 오류
 

1. 1xx (Informational)

• 거의 사용하지 않음

2. 2xx (Successful)

• 200 OK

• 201 Created

• 202 Accepted

• 204 No Content

3xx (Redirection)

• 300 Multiple Choices

• 301 Moved Permanently

• 302 Found

• 303 See Other

• 304 Not Modified

• 307 Temporary Redirect

• 308 Permanent Redirect

4xx (Client Error)

5xx (Server Error)