틀린 부분이 있다면 지적해 주시면 감사하겠습니다. 공부에 많은 도움이 됩니다.
WEB (World Wide Web)
웹 = 인터넷?
인터넷이라는 거대한 네트워크 위에서 다양한 서비스들이 동작하는데, 웹도 인터넷의 서비스 중의 하나이다.
서로 다른 컴퓨터에 서로 다른 정보들이 저장되어 있을 때, 원하는 정보를 얻기 위해서는 해당 정보가 저장된 컴퓨터로 로그온 해야했고, 컴퓨터마다 다른 프로그램을 사용하기 때문에, 만약 처음 보는 프로그램이라면 이것이 어떻게 돌아가는지 알기 위해 새로운 프로그램에 대해 매번 학습해야 했다.
당시 빠르게 발전하고 있던 인터넷과, HyperText 같은 컴퓨터 기술들을 활용하여 위의 문제점들을 해결하고자 했고, 이를 바탕으로 오늘날의 웹이 탄생했다.
HyperText
참조(하이퍼링크)를 통해 독자가 한 문서에서 다른 문서로 즉시 접근할 수 있는 텍스트
웹 (World Wide Web)
인터넷에 연결된 컴퓨터를 통해 사람들이 정보를 공유할 수 있는 전 세계적인 정보 공간을 말한다.
웹의 존재의 이유는 자원(정보)의 공유이며, 수많은 요청과 응답의 사이클로 이루어진다.
서버와 클라이언트
서버(Server)
클라이언트에게 네트워크를 통해 정보나 서비스를 제공하는 컴퓨터 시스템(프로그램 또는 장치)
클라이언트(Client)
서버가 제공하는 서비스를 요청하고, 또는 서비스 요청을 위해 필요 인자를 서버가 원하는 방식에 맞게 제공하며, 서버로부터 반환되는 응답에 사용자에게 적절한 방식으로 표현하는 기능을 가진 프로그램이나 시스템이다.
클라이언트는 원하는 자원을 요청하고
서비스는 클라이언트에게 요청을 받고 해당 요청에 대한 자원을 응답해준다.
HTTP (HyperText Transfer Protocol)
HTTP
웹상에서 정보를 주고받을 수 있는 프로토콜로, 주로 HTML 문서를 주고받는 데 쓰인다.
클라이언트와 서버 사이에 이루어지는 요청/응답 프로토콜이다. 예를 들면 클라이언트인 웹 브라우저가 HTTP를 통하여 서버로부터 웹페이지(HTML)나 그림 정보를 요청하면, 서버는 이 요청에 응답하여 필요한 정보를 해당 사용자에게 전달하게 된다. 이 정보가 모니터와 같은 출력 장치를 통해 사용자에게 나타나는 것이다.
TCP 와 UDP 방식이 있으며 80 포트를 사용한다.
특징
1.비연결성(Connectionless)
클라이언트의 요청에 대해 서버가 응답을 마치면 연결을 끊는다. 다음 요청은 새로운 연결을 통해 이루어진다.
불필요한 연결을 하지 않아 서버 유지 자원을 효율적으로 사용이 가능하지만, 매번 모든 요청에 대해 새로운 연결과 해제가 이루어지기 때문에 네트워크 비용측면에서 비효율적이다. (오버헤드가 발생한다)
위의 단점을 보완하고자 Keep-Alive 헤더가 생겼다.
Keep-Alive 헤더를 통해 지정된 시간동안 연결을 유지할 수 있다.
HTTP/1.1 200 OK
Connection: Keep-Alive
Keep-Alive: timeout=5, max=1000
...
위의 Header에서는, 5초동안 최대 1000번의 요청동안, HTTP Connection이 끊어지지 않고 유지된다.
HTTP 1.1부터는 기본적으로 keep-alive로 동작한다.
2.무상태성(Stateless)
하나의 요청이 진행되는 동안에만 서로를 인지한다. 즉 서버가 클라이언트의 상태를 저장하지 않는다.
손님 : 레몬에이드는 얼마인가요?
직원 : 4000원입니다.
손님 : 이거 주세요
직원 : 이게 어떤건가요?
손님 : 카드결제 할게요
직원 : 어떤 상품을 몇 개 구매하시나요?
위의 예시처럼, 직원이 손님의 이전 상태를 저장하지 않는 것이 Stateless이다.
손님 : 레몬에이드는 얼마인가요?
직원 : 4000원입니다.
손님 : 레몬에이드 두 잔 구매할게요.
직원 : 8000원입니다. 현금결제이신가요 카드결제이신가요?
손님 : 레몬에이드 두 잔을 카드로 결제하겠습니다.
직원 : 8000원 결제되었습니다. 감사합니다.
위의 대화에서 알 수 있듯이 요청을 보낼 때 클라이언트가 계속해서 추가 데이터를 전송해야하는 문제점이 발생하지만, 항상 같은 서버에 연결될 필요가 없으므로 서버를 보다 높은사양으로 업그레이드 하기가 용이하다.(Scale Up)
위의 대화에서, 손님이 계속해서 이전 상태를 업데이트하여 주문을 진행한다. 이처럼 클라이언트의 이전 상태를 모르기에, 인증이 필요한 서비스에서 불편함이 있으며, 이를 보완하기 위해 쿠키와 세션, 토큰 등을 활용해 클라이언트의 상태를 기억할 수 있다.
다시 정리하자면 아래와 같다.
Request-Response 과정에서만 연결이 되고, 사용이 되지 않을 때는 연결을 끊어버린다.(Connectionless)
클라이언트의 상태를 저장하지 않는(Stateless) 단순한 과정을 거친다.
위의 특징들을 통해 알 수 있듯이 단순하며, 서버의 확장에 용이하다.
상태코드
클라이언트의 요청에 대한 처리 상태를 숫자 코드로 반환한다.
HTTP 상태 코드 - HTTP | MDN
HTTP 응답 상태 코드는 특정 HTTP 요청이 성공적으로 완료되었는지 알려줍니다. 응답은 5개의 그룹으로 나누어집니다: 정보를 제공하는 응답, 성공적인 응답, 리다이렉트, 클라이언트 에러, 그리고
developer.mozilla.org
요약
100번대 : 정보 응답
200번대 : 성공 응답
300번대 : 리다이렉션 메세지 (요청 완료를 위해 추가 작업 조치 필요)
400번대 : 클라이언트 에러
500번대 : 서버 에러
요청 메서드
HTTP는 요청 메서드를 정의하여 주어진 리소스에 수행하길 원하는 행동을 나타낸다.
HTTP 요청 메서드 - HTTP | MDN
HTTP는 요청 메서드를 정의하여, 주어진 리소스에 수행하길 원하는 행동을 나타냅니다. 간혹 요청 메서드를 "HTTP 동사"라고 부르기도 합니다. 각각의 메서드는 서로 다른 의미를 구현하지만, 일부
developer.mozilla.org
GET - 서버의 리소스를 조회 (READ)
POST - 서버에 리소스 생성 (CREATE)
PUT - 서버의 리소스 수정 (UPDATE)
DELETE - 서버의 리소스 삭제 (DELETE)
HEAD - GET과 동일하지만, body를 포함하지 않는다. 리소스의 확인 용도로 사용
PATCH - 리소스 부분만 수정 시
OPTIONS - 지원 가능한 메서드의 종류를 알아볼 때
TRACE - 리소스의 경로를 따라 메세지 loop-back 테스트 실행
CONNECT - 리소스로 식별되는 서버로 터널을 맺을 때
동작 과정
1. 사용자가 브라우저에 URL을 입력
2. 브라우저는 DNS를 통해 서버의 진짜 주소를 찾음
3. HTTP 프로토콜을 사용하여 HTTP 요청 메세지를 생성함
4. TCP/IP 연결을 통해 HTTP요청이 서버로 전송됨
5. 서버는 HTTP 프로토콜을 활용해 HTTP 응답 메세지를 생성함
6. TCP/IP 연결을 통해 요청한 컴퓨터로 전송
7. 도착한 HTTP 응답 메세지는 웹페이지 데이터로 변환되고, 웹 브라우저에 의해 출력되어 사용자가 볼 수 있게 됨
예시 1 - 게시글 접근 시(GET)
해당 게시글의 접근 상황을 예시로 들어보자.
아래의 이미지는 크롬 개발자 도구 네트워크 탭에서,
https://mag1c.tistory.com/323 페이지 접근 시의 요청과 응답 정보를 담고 있는 헤더이다.
1. 해당 페이지에 대한 요청을 Request Header에 담아 서버로 전송하고
2. 서버는 요청 헤더에 담겨 있는 요청에 대한 정보(URI, Method 등)와 클라이언트 정보(accept, user-agent, cookie 등)을 확인한다.
3. 요청에 맞는 로직을 수행하며, 반환 페이지에 해당하는 html 파일을 찾은 후 요청에 대한 응답 헤더를 생성한다.
4. 서버가 클라이언트에게 응답한다.
5. 클라이언트가 응답을 받은 후 필요한 리소스(CSS, JS 등)들이 있다면 추가 요청을 하여 응답을 받는다.
6. 클라이언트(웹 브라우저)가 모든 리소스 요청에 대한 응답을 받는다.
렌더링 과정을 통해 받은 모든 리소스들을 통합하여 화면에 View한다.
HTTP 헤더는 body 및 요청/응답에 대한 정보를 포함하고 있다.
HTTP통신에 대한 일반적인 정보가 포함된 일반 헤더(Genereal Header)와, 요청/응답 헤더, 엔터티 헤더로 나뉜다.
엔터티 헤더
실제 메시지 또는 전송중인 Body에 대한 정보가 포함된다.(컨텐츠 길이, 언어, 인코딩, 만료 날짜 및 기타 정보)
예시 2 - 글 작성(POST)
위와 같은 게시글을 작성한 후의 요청과 응답을 살펴보자.
게시글 작성 시 POST 메서드를 통해 동작한다.
GET 요청과는 다르게, Request Payload라는 요청이 JSON형태로 추가되었다.
Payload는 POST, PUT과 같은 요청을 보낼 때, 전송되는 데이터이다.
Payload의 데이터대로, 요청이 완료되면 응답을 보내준다.
Response를 통해 임시 저장이 성공되었으며, 일련번호(sequence) 2번으로 저장이 되어있으며, 임시 저장이 된 게시물 수는 2건이다. 라는 것을 알 수 있다.
예시 3 - 작성한 글 삭제 (DELETE)
삭제 요청 시, DELETE 메서드를 통한 요청이 진행되었으며, 성공 상태까지 확인할 수 있다.
(total : 0인 이유는 다 삭제하고 마지막 임시 저장글에 대한 콘솔을 찍었기 때문이다..)
참조
https://ko.wikipedia.org/wiki/HTTP
https://velog.io/@leesomyoung/HTTP-%ED%94%84%EB%A1%9C%ED%86%A0%EC%BD%9C%EC%9D%98-%ED%8A%B9%EC%A7%95
2023.04 ~ 백엔드 개발자의 기록
포스팅이 좋았다면 "좋아요❤️" 또는 "구독👍🏻" 해주세요!
