[Web Session] http 웹 기본 지식

모든 개발자를 위한 HTTP 웹 기본 지식 - 인프런 | 강의

위 강의를 통해 공부한 내용을 정리함

 

안녕하세요!!

٩( *˙0˙*)۶

front-end 코어 멤버 김지혜입니다

 

 

 

 

"웹 개발자라면 알아야 할 http 기본 지식" 을 주제로 진행한 speaker session 포스팅입니다!

 

링크 걸어둔 강의를 참고하여 세션을 준비하였고 백, 프론트 모두 도움이 되는 내용이니 세션에 참여하지 않으셨던 분들도 포스팅을 통해 조금이라도 배워가는 부분이 있으셨으면 좋겠습니다!

 

(시간 관계상 강의의 모든 내용을 담지는 못했으나 중요하다 생각되는 부분은 거의 작성했습니다)

 

 

 

 

 

인터넷 통신

클라이언트와 서버는 통신을 할 때 1:1로 연결되어 있는 것이 아니다.

중간에 인터넷이라는 여러 노드들을 거치게 된다

클라이언트와 서버 주소 위치 정보 (= IP) 가지고 통신은 할 수 있는데..

 

 

• 패킷 손실
  • 노드 중 하나에서 송/수신 실패 
  • 서버에서 송/수신 실패

 

• 패킷 순서
  • 송신 패킷 순서와 수신 패킷 순서가 다를 수 있음

 

위와 같은 문제가 있을 수 있음

 

말그대로 통신은 되는데 통신이 제대로 이루어짐을 보장할 수가 없음 ..

 

그래서 나온 게TCP / UDP 프로토콜 (전송 계층)

 

TCP / UDP

패킷에 IP 정보만 명시하는 게 아니라 PORT, 전송 제어, 순서 , 검증 정보 등의 통신을 위한 다른 정보들을 명시한다.

→ TCP/UDP 프로토콜

• TCP 프로토콜의 특징

연결 지향 (3 way handshake) 논리적 연결 

데이터 전달 보증

순서 보증

• UDP 프로토콜

TCP 프로토콜이라는 제약이 강한 규약을 하나 만들어 놨음. (이건 이제 변경 불가능)

근데 TCP는 신뢰할 수 있는 프로토콜인 만큼 시간이 오래 걸릴 수 있음.

그래서 UDP를 만들어서 최적화의 여지를 남겨둠. 

 

최소한의 조건 (PORT, 체크섬)만 남겨두고 나머지들은 필요한 경우 추가해서 사용하면 됨. 

TCP 기능 거의 적용 안됨. (연결 지향, 전달 보장, 순서 보장)

TCP만 쓰다가 요샌 UDP도 쓰는 추세

 

PORT

서버 하나에서 여러 연결이 있을 수 있음.

이런 동시에 발생하는 연결들을 구분하는 게 PORT

 

서버를 찾는 것 : IP             ▷ 아파트

해당 서버에서 돌아가는 애플리케이션을 찾는 것 : PORT             ▷ 동/호수

 

 

 

DNS

 

IP로 서버를 구분하는데 IP만으로 구분하는 것은 문제가 있음

 

1. IP는 외우기 어려움 (xxx.xxx.xxx.xxx:port 이거 사이트마다 외울 순 없음)
2. IP가 변경될 수 있음 (겨우 xxx.xxx.xxx.xxx:port 외웠는데 변경되면..?)

∴ DNS 서버를 하나 두고 IP 주소를 알기 쉬운 주소와 매핑해서 사용

 

URL ?? URI ?? URN ??

리소스가 있는 위치를 지정

 

어떤 프로토콜로

어떤 호스트(IP), 포트에

어떤 경로로

어떤 파라미터를

 

보내는지 정의해서 리소스를 요청할 수 있는 식별자 역할을 한다.  

거의 url = uri 라고 생각하면 되고 urn은 잘 사용하진 않는다.

 

 

웹 브라우저의 요청 흐름

 

 

1. 애플리케이션 계층에서 웹 브라우저가 URL 정보를 가지고 HTTP 메시지를 생성한다. 
2. 애플리케이션 계층에서 OS 계층으로 socket 라이브러리를 통해 전달
3. OS 계층(TCP/UDP/IP)에서 TCP, UDP, IP 패킷 달고 네트워크 인터페이스 계층으로 전달 

 

 

HTTP

HyperText Transfer Protocol

통신할 때 사용하는 방식 중 원탑

HTML TEXT IMAGE 음성 영상 파일 JSON XML 거의 모든 형태의 데이터 전송에 쓰임

서버 간에 데이터를 주고받을 때도 거의 HTTP 사용

 

→ 지금은 HTTP 시대!

 

HTTP 1.*

HTTP 2.*

HTTP 3.*

 

버전이 있는 데 사용 기준은 거의 HTTP 1.1 이고 이후 버전들은 성능 위주

 

HTTP 특징

 

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

1. 클라이언트 서버 구조

 

request 랑 response를 구분해서 클라이언트와 서버가 각각 통신에 제약 없이 독립적으로 진화할 수 있음

 

2. 무상태 프로토콜

 

stateful (상태 유지) vs stateless (상태 비 유지)

 

클라이언트와 통신하면서

 

클라이언트가 준 정보 (상태)를 서버가 저장하고 있으면 → stateful

클라이언트가 준 정보 (상태) 를 서버가 저장하지 않으면 → stateless

 

장, 단점이 있는데 예시와 함께 생각해보면,

 

상태 유지의 경우 서버가 이미 저장하고 있는 상태에 대한 정보는 안 줘도 되니까 요청이 상태 비 유지에 비해 당연히 간결하다. 하지만 만약 중간에 통신하고 있는 서버에서 문제가 발생하거나 클라이언트 요구가 갑자기 많아지면 서버를 변경하거나 증축하는 데 있어 한계가 있다.

 

상태 비 유지의 경우 서버가 저장하는 게 하나도 없어서 클라이언트에 대한 정보를 요청 시에 모두 보내줘야 해서 요청이 길어진다. 하지만 서버에서 문제가 발생해서 서버를 변경하거나 서버를 증축해야 하는 경우 확장에 용이하다.

 

정리하면, 

 

	상태 유지	상태 비유지
장점	요청 간결	서버 활용 + 확장성
단점	서버 한정	요청 복잡 + 약한 연결 보장

 

 

HTTP는 이런 상태 유지, 상태 비 유지 중에 상태 유지의 특징을 가지고 있다.

 

상태 유지의 단점인 약한 연결성은 TCP/IP (3-way handshake + persistent connections)로 보완을 한다. 

 

HTTP 메시지

HTTP 통신에서 모든 데이터는 HTTP 메시지로 담겨서 보내지며 이런 HTTP 메시지는 프로토콜이니 당연히 정해진 규칙이 있음.

 

시작 라인 

 

요청 시에는 요청 메서드, 요청 대상, HTTP 버전

응답 시에는 HTTP 버전, 상태 코드

 

헤더

 

HTTP 전송에 필요한 부가 정보들에 대한 정보! (메시지 바디에 대한 정보, 인증, 압축, 캐시 등등...)

 

메세지 바디

 

말 그대로 주고받는 메시지 그 자체 

 

 

 

 

이 규칙대로 담고, 이 규칙대로 풀어서 메시지를 주고받는 것이 HTTP 통신!

 

 

좋은 API URI 설계

좋은 API URI 설계란?

 

가장 중요한 것은 리소스 식별!

 

URL 짤 때 메서드를 기준으로 하면 절대 × 무조건 리소스를 기준으로 해야 하고 리소스는 간단하게 설명하면 테이블이라고 할 수 있다.

 

만약에 회원에 대한 API를 짠다고 가정하면 회원 정보를 가져오고, 수정하고, 삭제하고 이 모든 걸 URI로 나누면 안 된다.

여기서 중요한 건회원 그 자체 아마 짜면 /api/members 이런 식으로 짜고 각각의 행위는 HTTP 메서드로 나눠주면 된다.

URI는 리소스만 식별하고 행위에 대한 구분은 HTTP 메서드로 해준다.

 

 

 

HTTP 메서드

 

GET

리소스 조회

서버에 전달하고 싶은 데이터는 쿼리 파라미터를 통해 전달

※ 메시지 바디를 사용할 수 있긴 하지만 지원을 하지 않는 곳이 많아서 GET 요청시 메세지 바디 쓰는 것은 권장하지 않음

 

POST

리소스 등록

메세지 바디를 통해서 서버로 요청 메세지 전달

다른 메서드들보단 요청이 그렇게 구체적이진 않아서 요청 데이터를 어떻게 처리할지는 리소스마다 다르다.

(→ 만만한 게 POST)

 

PUT

리소스 수정 or 생성

리소스가 있으면 수정하고 없으면 생성한다. 쉽게 이야기해서 덮어쓴다.

 

PATCH

리소스 부분 수정

PUT과 비슷한데 부분 변경한다는 차이가 있다.

 

DELETE

리소스 삭제

 

 

 

HTTP 메서드 속성

 

• 안전 → 요청이 리소스에 영향을 끼치는지
• 멱등 → 요청 한 번 한 거랑 요청 여러번 한거랑 응답이 같은지 (외부 요인으로 중간에 리소스가 변한 건 제외)
• 캐시 가능 → 거의 GET, HEAD 만 캐싱

 

 

 

 

 

 

 

마지막으로 준비했던 발표 자료입니다.

슬라이드와 발표 대본 참고해주세요!

GDSC-core_member-session_http

 

찐 마지막으로

내용 정리해둔 제 블로그 링크입니다.

위에 정리한 내용과 일치하는데 그냥.. 한번 더 봐주십사.. (혹시 몰라 못 넣은 강의 자료 이미지들 있어요!)

'- 공부/HTTP' 카테고리의 글 목록

 

 

 

읽어주셔서 감사합니다~~

앞으로도 도움 되는 다양한 세션 진행해봐요!!

(۶•̀ᴗ•́)۶