이번 토픽에서 배울 내용

• 웹 브라우저와 서버 사이에 이루어지는 통신에 대해 배움

fetch 함수 사용해보기

• 웹 브라우저가 서버로부터 받는 것은 결국 코드 덩어리이고 웹 브라우저가 이를 해석해서 화면을 보여줌

fetch(`https://www.google.com')
	.then((response) => response.text())
	.then((result) => { console.log(result); });

fetch 함수 살펴보기

• request: 웹브라우저가 서버로 보낸 요청
• response: 서버가 다시 보내는 응답
• fetch 함수: 서버로 리퀘스트를 보내고 리스폰스를 받는 함수
  • 파라미터로 넘어온 url로 리퀘스트를 보냄
  • 서버로 부터 리스폰스가 오면 그 리스폰스를 받음
    1. fetch 함수는 Promise 객체를 리턴함
    2. 이 객체의 then 메소드로, '리스폰스가 왔을 때 실행할 콜백'을 등록할 수 있음
    3. 이렇게 등록된 콜백들은 then 메소드로 등록한 순서대로 실행되고, 이때 이전 콜백의 리턴값을 이후 콜백이 넘겨받아서 사용할 수 있음
• 콜백: 나중에 어떤 조건이 만족되었을 때 실행되는 함수
• then 메소드: 콜백을 등록해주는 메소드
  • fetch 함수가 리턴하는 promise 객체의 메소드
  • 리턴값인 response.text()가 다음 콜백의 result 파라미터로 넘어감

fetch(`https://www.google.com') // 파라미터로 넘어온 url로 리퀘스트를 보냄 
	.then((response) => response.text()) // 서버로 부터 리스폰스가 오면 실행되는 콜백 함수 (fetch화 함께 실행되는 게 아님)
	.then((result) => { console.log(result); }); // 윗줄의 콜백이 실행되고 난 후에 실행됨 (이전 콜백의 리턴 값을 다음 콜백이 받을 수 있음)

response 객체

• 이렇게 코드를 적어도 리스폰스의 내용을 출력할 수 있지 않나요?

fetch('https://www.google.com')
  .then((response) => { console.log(response); });

• response 파라미터로는 리스폰스의 실제 내용 자체가 넘어오는 게 아님
• response 파라미터에는, 리스폰스에 관한 각종 부가 정보들과, 실제 내용을 함께 갖고 있는 하나의 객체(object)가 넘어옴
• 그래서 우리가 원하는 리스폰스의 실제 내용을 보려면 reponse 객체의 text라는 메소드를 호출해야 함

웹이란?

• 웹: World Wide web의 줄임말로 전 세계적인 연결망을 나타내는 단어
  • 웹 브라우저를 통해 돌아다니는 가상의 연결망 세계
• HyperText: 웹 페이지에 적혀있는 텍스트 / 다른 텍스트에 대한 참조를 갖고 있는 텍스트
  • HTML: HyperText Markup Language / 하이퍼텍스트를 마크업하는 언어라는 뜻

URL이란?

• Uniform Resource Locator: 웹에 존재하는 특정 데이터를 나타내는 문자열
  • 호스트: 전 세계 서버 중 하나의 서버를 특정
  • 경로(path): 서버에 있는 데이터 중 원하는 데이터를 특정
    • 서버마다 정해진 규칙이 다름
  • 쿼리: url에 존재할 때도 있고 존재하지 않을 때도 있음
    - 데이터에 관한 세부적인 요구사항
    - 하나의 속성 이름에 등호와 값이 써 있고 각각의 속성은 &로 이어서 나타냄
    - 서버마다 정해진 규칙이 다름
    

URL과 리퀘스트

• 만약 우리가 위와 같은 URL을 입력하고 엔터를 치면 다음과 같은 일들이 순차적으로 발생합니다.

1. 웹 브라우저는 URL에서 호스트 부분을 보고, 전 세계의 수많은 서버들 중에서 정확히 어느 서버와 통신을 해야 하는지를 찾음
   • 이때 호스트 부분에 적힌 www.codeitshopping.com 같은 것을 도메인 네임(Domain Name)이라고 함
   • 도메인 네임: 특정 서버를, 외우기 어려운 IP 주소가 아니라 외우기 쉬운 문자열로 나타낸 것
     • 도메인 네임을 쓰는 것: 계층적인 구조를 이루고 있는 각 도메인의 이름을 오른쪽부터(상위 도메인부터), 왼쪽으로(점점 하위 도메인으로), 점(dot)으로 구분하면서 써나가는 작업
   • Domain Name Resolution: 해당 도메인 네임이 나타내는 특정 서버를 식별할 수 있음
     • 1단계 : 일단 내 컴퓨터는 기본적으로 설정된 네임 서버(Name Server)에 codeit.kr 의 IP 주소를 알려달라는 요청을 보냄
       • 네임 서버: 도메인 네임을 IP 주소로 변환하는 과정에 참여하는 서버들
       • 내 컴퓨터에서 맨 처음 어떤 네임 서버에 요청할 것인지는 미리 설정되어 있고, 기존의 설정에서 다른 네임 서버로 바꾸는 것도 가능함
       • 내 컴퓨터가 사용하는 네임 서버에 관한 설정은 OS마다 다름
     • 2, 3단계 : 내 컴퓨터의 요청을 받은 네임 서버는 이제 루트 네임 서버(Root Name Server)에 '.kr'로 끝나는 도메인 네임들을 관리하는 네임 서버의 주소를 알려달라는 요청보내고 루트 네임 서버는 '.kr' 네임 서버의 IP 주소를 알려줌
     • 4, 5단계 : 네임 서버는 '.kr' 네임 서버에게 'codeit.kr'의 IP 주소를 알려줄 수 있는, 'codeit.kr' 네임 서버의 IP 주소를 알려달라고 요청하고 '.kr' 네임 서버는 'codeit.kr' 네임 서버의 IP 주소를 알려줌
     • 6, 7단계 : 그럼 네임 서버는 'codeit.kr' 네임 서버에게 'codeit.kr'의 IP 주소를 알려달라고 요청하고 네임 서버는 'codeit.kr'의 실제 IP 주소를 응답으로 얻게 됨
     • 8단계 : 네임 서버는 내 컴퓨터에게 codeit.kr의 IP 주소를 알려주고, 제 컴퓨터는 이 IP 주소를 갖고 코드잇 서버와 본격적인 통신을 시작함
       • 매번 1부터 8까지의 단계가 항상 발생하는 것은 아님
       • 이미 한번 codeit.kr의 IP 주소를 받은 후에는 제 컴퓨터의 OS가 그 IP 주소를 보통 별도로 저장해두고 계속 사용하기 때문임
       • 또, 내 컴퓨터가 사용하는 가장 근처의 네임 서버 또한 자주 요청받는 도메인 네임에 대해서는 별도로 외부에 요청할 필요가 없도록 캐시(cache)로 관리하는 경우가 많음
       • 즉, 1~8 까지의 과정이 일어나는 경우는 일반적으로 처음 접속하는 도메인 주소인 경우임
         

2. (1)에서 어떤 서버와 통신해야 하는지를 식별하고 나면, 웹 브라우저는 해당 서버로 리퀘스트를 보냅니다. 이때 URL에서 path 이후의 부분들(보라색 표시한 부분, path와 query)을 리퀘스트에 담아서 보냄
3. 리퀘스트를 받은 서버는 리퀘스트에 담긴 path 이후의 부분들을 보고, 그것이 의미하는 데이터를 찾고, 찾은 결과를 리스폰스에 담아서 보내줌
4. 그럼 웹 브라우저는 받은 리스폰스의 내용을 갖고 사용자에게 보여줌
   • 이때 리스폰스의 내용이 HTML 코드, Javascript 코드 등에 해당하면 그에 맞는 예쁜 화면을 사용자에게 그려서 보여줌
   • 리스폰스의 내용에는 다른 종류도 많음

HTTP란?

• http: HyperText Transfer Protocol
• https: HyperText Transfer Protocol Secure

한 번의 접속, 여러 번의 Request

• 개발자 도구에서 Network 탭: 브라우저가 구체적으로 어떻게 생긴 리퀘스트를 보내고, 어떻게 생긴 리스폰스를 받는지를 보여줌
  
• 각각의 한 줄이, 하나의 '리퀘스트-리스폰스' 쌍임
• 브라우저가 하나의 페이지를 그릴 때는 첫 리스폰스의 내용 안에서 또다시 요구되는, 여러 가지 다른 것들을 구하기 위해 다시 여러 개의 리퀘스트를 보내는 것이 일반적임