메가테라 6주차 강의 요약(HTTP편)

샨티(shanti)·2022년 6월 12일
0

TIL

목록 보기
133/145

메가테라는 매 주 금요일 오후 6시에 주말동안 들어야 할 아샬님의 강의를 오픈합니다.
주말 내도록 강의를 충분히 듣고, 필기&질문 목록을 만들고 난 뒤에
이어지는 월~금요일동안 주어진 과제를 수행하는 플립드 러닝(flipped learning) 방법으로 공부합니다.


흑.. 5주차 강의 요약을 아직도 안했다.
과제를 못한게 아니라 안한게지...
마음에 계속 남아있긴 했는데... ㅠㅠ. 도저히 엄두가 안난다.
그래도 지난 숙제를 못했다고 하여 이번 숙제까지 밀릴수는 없기에!! 차근 차근 6주차 강의를 요약해본다.

메가테라 6주차 강의는 HTTP, HTML, CSS 총 3강을 구성되어있었다.
매우매우 감사하게도!!! HTML과 CSS는 3주차 강의와 동일했기 때문에 사실상 새로운 주제는 HTTP였는데...
그렇다고 내가 HTML, CSS를 아는 것도 아니더라. 그저 강의를 한 번 더 '시청'했을 뿐 공부해서 머릿속에 새겨놓은 것은 아니기에...

어찌되었건 HTTP, HTML, CSS 세 가지 주제를 강의 요약 글에서 모두 다루기에는 덩어리들이 크다보니 HTTP에 한정하여 요약해보고자 한다.


HTTP는 결국 '약속'

인터넷을 사용하는 사람이라면 누구나 한 번 이상 보았을 HTTP.

웹 브라우저 주소창에 우리가 흔히 아는 URL 주소를 입력한다고 치자.
예를 들어 구글 주소를 입력한다면 www.google.com 이나 또는 google만 치고 엔터를 누르는 사람도 있을 것이다.

여튼, 무엇을 치더라도 화면이 전환되고 나서 주소창을 한번 클릭한 뒤에 방향키로 좌 우 왔다갔다 해보면 숨어있던 'http' (또는 'https')가 나타나는 것을 볼 수 있다.

강의를 듣기 전까지 나는 http가 단순히 URL구성 요소라고 생각했는데...
HTTP를 한마디로 정의한다면 '약속'이라고 할 수 있다는 점을 새롭게 알게 되었다.

HTTP : Hyper-Text Transfer Protocol

직역하면 '하이퍼텍스트(초본문) 전송 규약'
이름에서도 어느 정도 힌트를 얻을 수 있다.
'규약'. 말 그대로 규칙이고 약속인 것이다.

그럼 무엇에 대한 약속일까?
이 역시 이름에서 힌트를 얻을 수 있는데 바로 '전송'이다.

또다시 질문을 던져본다.
그럼 누가(Who), 무엇을(What) 전송한다는 말인가?
(꼬리질문을 하고 대답을 달면 내가 놓치고 있는 부분이 무엇인지 알 수 있어서 좋다.)

전송하는 주체는 Client와 Server이고, 주로 HTML(Hyper-Text Markup Language) 문서를 주고 받는데 HTTP이 사용된다.
'주로' 라는 단서를 단 것 처럼, 반드시 HTML 문서를 주고받을 때 사용하는 것은 아니라는 점은 참고.


우리는 인터넷을 사용할 때 내가 원하는 페이지에 접속하고, 링크를 클릭했을 때 원하는 화면이 창에 뜨는 것에 익숙하다. 즉 이 과정이 '전송'의 과정이라고 인식하지는 않는다.

하지만 웹을 사용한다는 것은 수많은 '전송'과정의 연속이다. 좀 더 확장해서 이야기한다면 '통신'의 연속이라고 볼 수 있다.

사용자(user)가 쇼핑을 하기 위해 물품 상세 페이지 링크를 클릭하면, 웹 브라우저(client)는 서버(server)에 물품 상세 페이지 화면을 요청(request)하고, 서버(server)는 해당 요청에 대한 응답(response)을 웹 브라우저(client)에 전달한다. 이 응답에 대한 결과가 우리가 보고 있는 쇼핑몰 물품 상세 페이지인 것이다.

위 과정에서만 벌써 (1) 사용자(user), (2) 클라이언트(client), (3) 서버(server) 총 세 주체가 등장한다.

덧붙이고 넘어가는 것은 사용자와 클라이언트를 혼동하지 말 것!

웹을 이용하는 '나 자신'은 사용자(user)이고, 크롬이나 사파리 같은 웹브라우저를 클라이언트(client)라고 칭한다.

이를 도식화 한 것이 아래와 같다.

클라이언트와 서버(서버는 단일로 구성될 수도 있지만 여러개로 분화되어 있을 수도 있음)가 인터넷을 통하여 HTML을 포함한 문서들을 주고 받고 하는 통신과정(requests-responses)에서의 규약을 HTTP라고 정리할 수 있겠다.


HTTP의 기본적인 특징

MDN 웹 문서에서 확인할 수 있는 HTTP의 기본적인 특징 네 가지를 아래와 같이 정리해본다. 개인적으로는 3번 특징이 잘 이해가 가지 않는 부분이 있고(상태는 없으나 세션은 있다는 특징), 4번 특징은 별도로 공부해야 할 내용들이 있어서 서칭한 내용을 덧붙인다.

  1. 간단함
    기본적으로 컴퓨터는 2진수라는 체계로 소통하기 때문에, 나같은 컴알못(ㅎㅎ)이 컴퓨터의 2진수 소통 내용을 훔쳐본다 한들 단 한 글자도 해석하지 못할 가능성이 크다. 하지만 HTTP는 말 그대로 간단하고, 사람이 읽을 수 있는 언어로 되어있다. '규약'이기 때문에 규약에서 사용되는 약속이나 코드를 익혀둔다면 얼마든지 읽고 이해할 수 있다.

  1. 확장 가능함
    HTTP에는 'HTTP 헤더'라는 부분이 있는데, 이를 통해 확장이 가능하다.
    아샬님이 강의에서 쉬운 예시를 들어주셔서 금방 이해하게 되었는데, 예를 들어 편지를 쓰고 나서 편지봉투에 넣은 뒤 그 봉투에 어떤 내용을 기재하느냐에 따라 특급우편이 될 수도 있고, 일반 우편이 될 수도 있다는 점이다. 만약 편지봉투 위에 '긴급, 중요, 익일 특급' 등의 단어가 써 있다면 편지의 내용은 변하지 않았으나 봉투위에 적은 메시지로 인해 편지의 성격이 '특급우편'으로 변한다는 것이다.

마찬가지로 mdn web docs 문서에 있는 HTTP 요청(requests)의 예시이고 앞으로의 과제(ㅎㅎ)를 위하여 header의 위치와 주요 구성 요소들을 눈에 익혀두어야겠다.


  1. 상태는 없으나 세션은 있음
    전통적인 클라이언트-서버의 소통방식은 아래와 비슷하다고 볼 수 있겠다.
    한번의 요청-응답 사이클이 돌 때, 인간의 면대면 대화라면 상호작용, 즉 대화의 연속성이 생기지만 클라이언트-서버의 소통방식은 그것과는 다르다.
    즉 맥락과 상태를 저장하지 않기 때문에(stateless) 페이지와 일관되게 상호작용을 하려는 순간 문제가 발생한다.
    이를 해결하는 것이 '쿠키'이고, 쿠키는 상태가 있는 세션을 만들도록 해 준다.

    #상황. 철수(client)가 영수와 놀기 위해 영수네(server)로 전화를 건다.
    철수: 안녕하세요, 혹시 영수 있나요?
    영수엄마: 응~ 영수 화장실 갔는데... 근데 누구니?
    철수: (철컥. 전화를 끊는다)
    영수엄마: (...?)
    철수: (다시 전화를 건다) 어, 저 지금 방금 전화했던 사람인데요~
    영수엄마: 누구니? 방금 전화를 여러통 받아서... 누군지 모르겠네~
    철수: (철컥. 전화를 또 끊는다)


  1. 연결과 관련한 특징

    HTTP의 연결 자체는 '전송계층'에서 이루어진다. 즉, HTTP영역 밖에서(HTTP 하부계층) 이루어진다.
    이해를 돕기 위하여 아래의 그림을 effortDev 블로그에서 가져왔다.

    좌측은 OSI 7 레이어 모델, 우측은 TCP/IP 프로토콜인데 자세히 보면 우측 TCP/IP 프로토콜의 붉은색 부분인 Application 영역에 HTTP가 포함되어 있음을 볼 수 있다.
    하지만 HTTP의 연결 자체는 하단부 초록색 영역인 Transport(전송계층)에서 이루어진다는 것이다.
    OSI 7 Layer Model이나 TCP/IP Protocol에서 뎁스있게 공부해야 하는지는 아직 판단이 잘 안서지만... 적어도 MDN 문서에 나오는 내용은 숙지해야 할 것 같다.

예시로 보는 HTTP 메시지

아래에 나오는 모든 예시의 출처는 mdn web docs임을 미리 밝혀둔다.

(1) HTTP 요청의 예

  • Method: 보통 클라이언트가 수행하고자 하는 동작을 정의한 동사나 명사
  • 기억해 둘 메소드의 종류
    - GET: 특정 리소스의 표시를 요청함. 오직 데이터를 '받기만(가져오기만)' 하기 때문에 바뀌는 것이 없음. seeing하기 위해 리소스 표시를 요청하는 것으로 이해할 것
    - HEAD: GET 메서드의 요청과 동일한 응답을 요구하나, '헤더만' 얻을 때 씀. 즉 응답의 본문을 포함하지 않음
    - POST: create(생성)의 용도로 쓰이기도 하며 기본적으로는 고치고, 만드는 역할을 함
    - PUT: 바꾸거나 update 할 때 사용. 전체가 모두 바뀐다고 이해할 것
    - PATCH: PUT과는 다르게 리소스의 부분만을 수정하는 기능이라고 이해할 것
    - DELETE: 특정 리소스를 삭제함
    - OPTION: 호스트를 하기 전, 통신상태를 설정하고 상태를 확인하느니 용도로 사용됨

(2) HTTP 응답의 예

응답메시지의 예시를 보면서 각 구성 요소를 잘 기억하도록 하자.

  • 프로토콜 버전: 요청 메시지에서도 확인할 수 있는 부분! 응답메시지에도 동일하게 포함되어 있다.
  • 상태 코드(Status Code)와 상태 메시지(Status Message): 코드와 메지시를 통하여 현재 응답이 어떤 상태인지(성공하였는지, 실패하였는지, 실패했다면 이유는 무엇인지, 그 밖의 상태인지)를 알 수 있다.
    - 100번대: 거의 사용되지 않으므로 지금 당장 숙지할 필요는 없음
    - 200번대: 많이 사용됨. 이에 해당하는 모든 코드가 '성공 case'라고 이해하면 됨
    - 300번대: 'redirection'에 대한 내용.
    -> 단, 304 Not Modified 코드는 redirection과 관련이 없음. 브라우저가 처음 열리면 웹페이지를 다운받는데, 사용자가 새로고침을 누르더라도 해당 웹페이지 상 변동사항이 없다면 또다시 웹페이지를 다운받을 필요가 없음(불필요한 작업임). 따라서 "아까 다운 받은 페이지를 그대로 써라~" 하며 알려주는 것. 캐시를 무시하고 새로고침을 하기 원한다면 (Mac 기준) command + Shift + R 을 동시에 누르면 됨
    - 400번대: client 측에서 오류가 난 것(클라이언트의 잘못!)
    404 Not Found나 400 Bad Request와 같은 오류 메시지들을 한번쯤은 접해본 적 있을 것임 ㅎㅎ
    - 500번대: server 측 오류(server의 잘못!)
    일례로 500 Internal Server Error와 같은 메시지가 있는데, 서버 내부의 에러로서 사용자 입장에서는 할 수 있는 것이 아무것도 없다.
  • 헤더(Headers): 요청 헤더들과 비슷하며, 응답을 요청한 시각, 사용하는 서버 명칭, 해당 문서가 마지막으로 수정된 날짜, 어떤 타입으로 작성된 문서인지 등의 정보를 포함

굉장히 많은 정보가 쏟아진 것 같지만, 사실 위에 기술한 내용들은 HTTP의 개요도 채 되지 않을 것이다.

이런 내용들을 가지고 이번 한주간 또 어떤 공부를 하게 될지 궁금...!!

HTTP와 더불어 HTML, CSS의 경우에는 JAVA 처럼 외워야 할 것들이 굉장히 많아보이는데... 지치지 말고 잘 외워나갔으면 좋겠다!!!

6주차도 화이팅!


참고 사이트

profile
가벼운 사진, 그렇지 못한 글

0개의 댓글