[코드스쿼드] 프론트엔드 Lv3 - HTTP 이해

in Devlog on HTML, CSS


웹 자판기 - HTTP의 이해

브라우저에서 네이버로 접근한다. 브라우저에서 서버에 요청을 보내고 응답을 받아 화면에 출력하기 까지의 과정은 어떻게 될까?

[검색 전 & 학습 전]

  1. 일단 사용자의 클라이언트(브라우저)에서 네이버로 가는 IP주소를 찾기위해 DNS 서버로 접근 후 요청한다.
  2. DNS 서버에서 네이버의 본래 IP 주소를 담은 정보를 응답받고 해당 IP 주소로 접근하기 전에 클라이언트(브라우저)의 Cache 쪽으로 접근한 후, 네이버에 방문한 기록(헤더파일) 이 있는지 확인한다.
  3. 헤더파일이 있다면, 마지막으로 업데이트 한 날짜를 확인한다(?)
  4. 이후, 네이버쪽에 헤더파일을 요청한 후, 업데이트 한 날짜가 동일하다면 Cache 에서 빠르게 불러온 후, 클라이언트(브라우저)에 출력한다.
  5. 그러나 네이버쪽의 업데이트 날짜가 최신이라면 변경된 내용만 요청한다.
  6. 그리고 네이버쪽에서 응답받은 후, 클라이언트(브라우저)에 출력한다.

[학습 해야할 것]

  1. 브라우저는 IP:PORT 형식으로 웹 서버와 연결함 (기본포트 80)

  2. 웹 서버에 요청을 보냄

  3. 웹 서버는 HTML을 생성한 후 응답을 보냄

  4. 브라우저는 응답을 받은 후 웹서버와의 연결을 끊음

  5. 브라우저는 응답 헤더와 HTML을 읽은 후, 웹 자원에 대한 재 요청을 함 대표적인 웹 자원은 JavaScript, CSS, Image 등 이 존재함

  6. HTTP (Hypertext Transfer Protocol)

    • HTTP (Hypertext Transfer Protocol) is perhaps the most popular application protocol used in the Internet (or The WEB).
    • HTTP is a stateless protocol. In other words, the current request does not know what has been done in the previous requests.
    • HTTP permits negotiating of data type and representation, so as to allow systems to be built independently of the data being transferred.

  7. URL (Uniform Resource Locator) URI (Uniform Resource Locator)

    A URL (Uniform Resource Locator) is used to uniquely identify a resource over the web. URL has the following syntax:

    protocol://hostname:port/path-and-file-name
    • Protocol: The application-level protocol used by the client and server, e.g., HTTP, FTP, and telnet.
    • Hostname: The DNS domain name (e.g., www.nowhere123.com) or IP address (e.g., 192.128.1.2) of the server. OR 리소스가 존재하는 컴퓨터 이름
    • Port: The TCP port number that the server is listening for incoming requests from the clients.
    • Path-and-file-name: The name and location of the requested resource, under the server document base directory.
    • Scheme : 리소스를 획득하기 위한 방법 (Ex. HTTP, FTP, file, mailto)

  8. HTTP over TCP/IP

  9. HTTP와 관련된 알아야 할 용어들

    • URL
    • Request Line
    • HTTP Method
    • Query String
    • Status Line
    • Status Code

  10. Request Line

    The first line of the header is called the request line, followed by optional request headers.

    request-method-name request-URI HTTP-version
    • request-method-name: HTTP protocol defines a set of request methods, e.g., GET, POST, HEAD, and OPTIONS. The client can use one of these methods to send a request to the server.
    • request-URI: specifies the resource requested.
    • HTTP-version: Two versions are currently in use: HTTP/1.0 and HTTP/1.1.
    // EXAMPLE
GET /test.html HTTP/1.1
HEAD /query.html HTTP/1.0
POST /index.html HTTP/1.1

  11. HTTP Request Method

    HTTP protocol defines a set of request methods. A client can use one of these request methods to send a request message to an HTTP server. The methods are:

    • GET: A client can use the GET request to get a web resource from the server.
    • HEAD: A client can use the HEAD request to get the header that a GET request would have obtained. Since the header contains the last-modified date of the data, this can be used to check against the local cache copy.
    • POST: Used to post data up to the web server.
    • PUT: Ask the server to store the data.
    • DELETE: Ask the server to delete the data.
    • TRACE: Ask the server to return a diagnostic trace of the actions it takes.
    • OPTIONS: Ask the server to return the list of request methods it supports.
    • CONNECT: Used to tell a proxy to make a connection to another host and simply reply the content, without attempting to parse or cache it. This is often used to make SSL connection through the proxy.
    • Other extension methods.

  12. Query String

    Each field has a name and can take on a specified value. Once the client fills in the fields and hits the submit button, the browser gathers each of the fields’ name and value, packed them into “name=value” pairs, and concatenates all the fields together using “&” as the field separator.

    It will send the query string to the server as part of the request.

    name1=value1&name2=value2&name3=value3&...

    Special characters are not allowed inside the query string. They must be replaced by a “%” followed by the ASCII code in Hex. E.g., “~” is replaced by “%7E”, “#” by “%23” and so on. Since blank is rather common, it can be replaced by either “%20” or “+” (the “+” character must be replaced by “%2B”). This replacement process is called URL-encoding, and the result is a URL-encoded query string. For example, suppose that there are 3 fields inside a form, with name/value of “name=Peter Lee”, “address=#123 Happy Ave” and “language=C++”, the URL-encoded query string is:

    name=Peter+Lee&address=%23123+Happy+Ave&Language=C%2B%2B

    The query string can be sent to the server using either HTTP GET or POST request method, which is specified in the <form>’s attribute “method”.

    <form method="get|post" action="url">

    If GET request method is used, the URL-encoded query string will be appended behind the request-URI after a “?” character, i.e.,

    GET request-URI?query-string HTTP-version
(other optional request headers)
(blank line)
(optional request body)

    Using GET request to send the query string has the following drawbacks:

    • The amount of data you could append behind request-URI is limited. If this amount exceed a server-specific threshold, the server would return an error “414 Request URI too Large”.
    • The URL-encoded query string would appear on the address box of the browser.
      • ID 및 PASSWORD 가 QueryString 에 표시되는 보안적인 문제가 있음(?)

  13. Status Line

    The first line is called the status line, followed by optional response header(s).

    The status line has the following syntax:

    HTTP-version status-code reason-phrase
    • HTTP-version: The HTTP version used in this session. Either HTTP/1.0 and HTTP/1.1.
    • status-code: a 3-digit number generated by the server to reflect the outcome of the request.
    • reason-phrase: gives a short explanation to the status code.
    • Common status code and reason phrase are “200 OK”, “404 Not Found”, “403 Forbidden”, “500 Internal Server Error”.
    HTTP/1.1 200 OK
HTTP/1.0 404 Not Found
HTTP/1.1 403 Forbidden

  14. Response Status Code

    The first line of the response message (i.e., the status line) contains the response status code, which is generated by the server to indicate the outcome of the request.

    The status code is a 3-digit number:

    • 1xx (Informational): Request received, server is continuing the process.
    • 2xx (Success): The request was successfully received, understood, accepted and serviced.
    • 3xx (Redirection): Further action must be taken in order to complete the request.
    • 4xx (Client Error): The request contains bad syntax or cannot be understood.
    • 5xx (Server Error): The server failed to fulfill an apparently valid request.

    대표적인 HTTP Status Code

    • 200 - OK
    • 201 - Created
    • 302 - Found(HTTP 1.0)
    • 304 - Not Modified
    • 401 - Unauthorized
    • 404 - Not Found
    • 500 - Internal Server Error
    • 503 - Service Unavailable

  15. GET/POST 차이점

    • 검색 전

      GET 은 서버에 질의하는 성격을 가지고 있다 (?) Query String 에 정보가 보이기 때문에 공개적인 데이터만 주고받으며, GET, POST 둘다 보안이 안좋긴 한데 POST에 비해 상대적으로 보안이 취약하다. 그리고 제한 값이 있음.

      POST 는 서버에게 명령하는 성격을 가지고 있음, 값들을 바꿀 수 있다.

    • 검색 후

      GET은 가져오는 것이고 POST는 수행하는 것

      • GET은 Select적인 성향을 가지고 있습니다. GET은 서버에서 어떤 데이터를 가져와서 보여준다거나 하는 용도이지 서버의 값이나 상태등을 바꾸지 않습니다. 게시판의 리스트라던지 글보기 기능 같은 것이 이에 해당하죠.
      • POST는 서버의 값이나 상태를 바꾸기 위해서 사용합니다. 글쓰기를 하면 글의 내용이 디비에 저장이 되고 수정을 하면 디비값이 수정이 되죠. 이럴 경우에 POST를 사용합니다.
      • Google Accelerator 사건
      • Web의 Link 특성상 URL을 전송할 때 GET 방식이 아니라 POST 방식이라면 보고있는 웹페이지를 공유할 수 없음.

[질문 사항]

  1. 도메인(Domain)에 해당하는 IP를 찾는다 에서 브라우저 옆에 왜 DNS Client 인지 궁금합니다. Ondeman 방식(?)에 따라서 클라이언트(사용자 브라우저) 와 DNS Server가 먼저 통신했다가, DNS Server가 다른 DNS Server1 과 통신해야 하므로 DNS Server 가 DNS Client 로 표기된 것인가요?
  • 답 : DNS Client 는 로컬에 있는것이 맞다. 로컬에 이미 저장된 DNS 정보가 있다면 그것을 사용한다.
  1. 레벨2 에서 Array Parser 과정을 진행하면서 처음 설계했던 부분이 매우 미약하다는 것을 느끼게 되었습니다. (깊이가 깊지 않다?) 이런것은 계속된 훈련으로 진행되는 것인가요?
  • 답 : 설계가 미약하다고 느끼는 것은 끝이 없는 수준이다. 시간만 있다면 ArrayParser 를 다시 구현해보는 것도 방법이지만, 현실적으로는 어렵다. 작은단위라면 다시 설계-개발-설계 이런식으로 해보는 경험이 좋긴하다. 아마 난이도가 있는 것이라 처음의 설계가 많이 부족해보였을 수 있다. 자꾸 하면 늘게 된다.
  1. URL 에서 Protocol 부분이 코드스쿼드에서는 Scheme 라고 지칭되고 있었습니다. 그래서 왜 그런지 찾아보니 file://usr/share/doc 에서 file은 Protocol이라고 지칭할 수 없기 때문에(전송계층이나 인코딩이 존재하지 않음) Scheme 라고 지칭하는 것 같았습니다. 그렇다면 Protocol은 Scheme의 하위 계층인건가요 ? 관련은 없지만 계층적으로 URI - URL 구조인것인지 궁금합니다. Scheme 중 HTTP 는 Protocol 이다. (O) Scheme 중 file 은 Protocol 이다. (X) Protocol 은 Scheme 이다 (O)

  • 답 : URI에서 콜론 앞 부분이 scheme 는 맞다. Protocol 은 HTTP 에서 마지막 P 가 Protocol을 의미한다. 작성한 것 처럼 file 은 Protocol 이 존재하지 않는다.

    Protocol 은 서버와 통신을 하는 등에 필요한 약속된 정보들을 말하는 것인데, file은 그런 부분이 필요 없으니 프로토콜이 없는것이다.

    Scheme 와 Protocol의 관계가 있는 건 아니지만, URL Scheme 중에 Protocol 인 녀석이 있고 아닌 녀석이 있다 라고 할 수 있다.

    https://en.wikipedia.org/wiki/Uniform_Resource_Identifier 이쪽을 참고하면 더 좋은 답변이 될 것이다

  1. 그 document 들은 보통 영어로 된것들이 많잖아요. 보통.. 영어를 어느정도 까지 해야하는지 궁금해서요. 제가 영어가 많이 약한데, 실무에서도 번역기를 돌려가면서 보나요?
  • 답 : 번역기 볼 수 있다. @crong도 봄. 독해능력이 중요한 것 같다. 내용중에 코드가 있으면 더 좋다. 그래도 자꾸 영어를 직접 보려고 해봐야 한다. 금방 느는것은 아니니까
  1. 공식 문서(예를들어 MDN 이나 Android Developer 등) 를 자꾸 보려는 노력을 해야한다는 것은, 공식문서에서 원하는 정보를 찾는 능력을 말하는것인지 궁금합니다!
  • 답 : 아 우선 정보의 정확성/최신성 때문에 공식가이드를 보라고 하는거고요. (이상한블로그보다는 나으니까) 이런습관이 반복되면 그런가이드에 익숙해질테고, 더 빨리 원하는 정보를 얻게 되겠죠.
  1. mixin 방식 VS extends 방식

  • 답 : 넵 이건 정답은 없는 문제에요. 두 개의 차이점을 이해하는 정도가 의미있고, 본인이 선택해서 경험하면 될거라고 생각해요. 둘 다 사용됩니다.

    네 css 방법론은 다 제각각인상태에요. 다 경험하기는 어려우니, 쉬워보이고 간편해 보이는 걸 적용해보는 걸 추천합니다.

    장단점이 있는거니가요. 모두. 뭐가 좋다 안좋다라고 단정하는 논쟁은 좀 틀린거 같아요.




© 2018. by HYEON

Powered by HYEON