on
네트워크 기초
네트워크 기초
학습 내용
이번 시간에는 네트워크의 간단한 구성에 대해서 살펴보고자 한다. 사실 네트워크라는 과목은 한 학기를 수강해도 부족할 정도로 방대한 내용을 가진 과목이다. 그러나 지금은 일단 기본적인 내용을 학습하여 앞으로 네트워크를 공부하는 것에 기반을 닦는 시간으로 하고자 한다. 그래서 네트워크에 관련한 기본적인 작동 원리와 간단한 명칭 등을 학습하고 AJAX에 대해서도 간단히 정리한다.
클라이언트와 서버
웹 앱을 사용할 때 우리가 앱을 실행하면 데이터를 볼 수 있다. 그러나 만약 인터넷이 연결되지 않은 경우라면 우리는 데이터를 받을 수 없다는 것을 경험으로 알 수 있다. 이 이유는 우리가 사용하는 웹 앱의 데이터가 앱에 저장된 것이 아니라 특정 서버에 저장되어 있기 때문이다. 기본적으로 우리가 사용하는 앱인 클라이언트와 데이터를 제공하는 서버를 분리해두는데, 이것을 2티어 아키텍처 또는 클라이언트-서버 아키텍처라고 부른다. 이 경우 클라이언트가 리소스(자원, 데이터)를 '요청'하고 서버는 그 리소스를 제공하는 '응답'을 한다. 우리가 이용하는 앱들은 대부분 이런 식으로 작동한다. 여기서 주의할 점은 서버 역시 이 리소스를 보관하고 있는 것이 아니라는 것이다. 서버는 그냥 요청받은 리소스를 제공하는 역할을 한다. 즉, 서버는 리소스를 저장하고 있는 공간에서 요청받은 리소스를 가져오는 것이다. 이 공간을 데이터베이스라고 부른다. 이 것을 3티어 아키텍처라고 한다.
간단히 클라이언트와 서버에 대한 종류들을 살펴보면 클라이언트의 종류로 플랫폼에 따라 브라우저를 이용하는 웹사이트, 웹 앱과 스마트폰, 태블릿이나 데스크탑 플랫폼에서 이용하는 앱들로 분류할 수 있다. 서버는 역할에 따라 종류를 구분하는데, 파일을 제공하는 앱인 파일 서버, 웹사이트에서 필요로 하는 정보들을 제공하는 앱인 웹 서버, 그리고 메일을 주고받도록 도와주는 앱인 메일 서버 등이 있다. 데이터베이스도 엄밀히 말하면 데이터를 제공하는 일종의 서버라고 볼 수 있다.
클라이언트와 서버의 통신
클라이언트와 서버의 통신을 이해하려면 먼저 프로토콜에 대해 알아야 한다. 프로토콜이란 통신 규약이다. 클라이언트와 서버에서 서로 데이터를 주고받는다고 할 때, 둘의 소통을 위해 사용하는 규약이 필요하다. 이 규약이 바로 통신 규약이며 프로토콜이다. 당연히 제대로 된 통신을 위해서는 이 프로토콜을 반드시 지켜야 하는 것이다.
4Layer(전송계층) TCP HTTP,FTP 통신의 근간이 되는 인터넷 프로토콜 UDP 양방향인 TCP와 다르게 단방향으로 작동하는 훨씬 더 단순하고 빠르지만, 신뢰성이 낮은 인터넷 프로토콜
7Layer(응용계층) HTTP 웹에서 HTML, JSON 등의 정보를 주고 받는 프로토콜 SSH CLI 환경의 원격 컴퓨터에 접속하기 위한 프로토콜 HTTPS HTTP에서 보안이 강화된 프로토콜 RDP Window 계열의 원격 컴퓨터에 접속하기 위한 프로토콜 FTP 파일 전송 프로토콜 WebSocket 실시간 통신, Push 등을 지원하는 프로토콜 SMTP 메일을 전송하기 위한 프로토콜
우리가 특정 리소스를 요청할 때에 정확한 주문 방법(프로토콜)을 따라 요청해야만 한다. 그러나 우리는 서버가 어떻게 구성되어 있는지 모른다는 문제가 있다. 이런 점을 보안하기 위해 나온 것이 API(Application Programming Interface)이다. 즉, 서버가 클라이언트에게 리소스를 잘 활용할 수 있도록 인터페이스를 제공하는 것이다. 그래서 이 API를 잘 구축해 놓으면 클라이언트가 이를 활용할 수 있다. 예를 들어 인터넷에 있는 데이터를 요청할 때 HTTP 프로토콜을 사용하여 주소(URL, URI)를 통해 접근할 수 있는 것이다.
HTTP 요청 메소드
프로토콜에 따른 클라이언트가 웹 서버에서 사용자 요청의 목적과 종류를 알리는 수단이다. 이것을 알아야 알맞은 요청과 응답을 주고받을 수 있다.
1) HEAD
메시지 헤더(문서 정보)를 취득하는 메소드이다. GET과 유사한 방식이지만 실제 문서가 아니 문서 정보를 요청하는 메소드이다. 그래서 HTTP 응답 메시지에 body 없이 HTTP 헤더 정보만 나타난다.
2) GET
URI 형식으로 웹 서버 측 데이터를 요청하는 메소드이다. 파라미터를 넘겨 해당하는 본문 형식을 전달받는다. 만약 서버에 파라미터를 보낼 때 URL에 찍히는 것이 싫다면 POST로 요청해야 한다.
3) POST
내용을 전송하는 메소드이다. 클라이언트에서 서버로 전달하고자 하는 정보를 보낼 때 사용한다. 파일 전송이 가능하다.
4) PUT
POST와 유사하지만 내용을 갱신하는 것이 주목적이다. 이 역시 파일 전송이 가능하다.
5) DELETE
파일을 삭제하는 메소드이다. 웹 리소스를 제거할 때 사용한다. 다만 DELETE의 경우 서버에서 클라이언트의 요청을 무시하는 것이 가능하기 때문에 실제로 삭제되지 않았지만, 클라이언트는 파일이 삭제되었다고 착각하게 할 수 있다.
6) OPTIONS
사용이 가능한 메소드 옵션에 대한 것을 물을 때 사용하는 메소드이다. 이 메소드를 사용하면 응답 메시지로 HTTP 헤더 항목 중 'Allow: GET, POST, HEAD'와 같이 보낸다.
7) TRACE
요청 리소스가 수신되는 경로를 보여주는 메소드이다.
8) CONNECT
프록시 서버와 같은 중간 서버를 경유하게 하는 메소드이다. 이 메소드를 사용하면 요청한 리소스에 대해 양방향 연결을 시작한다. SSL(HTTPS)를 사용하는 웹 사이트에 접속하는 데 사용할 수 있다. 클라이언트가 원하는 목적지와 TCP 연결을 HTTP 프록시 서버에 요청하는데, 이때 서버는 클라이언트를 대신하여 연결의 생성을 진행한다. 한번 서버에 의해 연결이 수립되면, 프록시 서버는 클라이언트에 오고 가는 TCP 스트림을 계속해서 프록시한다.
URL과 URI
URL(Uniform Resource Locator)은 네트워크 상에서 웹 페이지, 이미지, 동영상 등의 파일이 위치한 정보를 나타낸다. URL은 scheme, hosts, url-path로 구분한다. scheme은 프로토콜을 결정한다. 대부분 일발적인 웹 브라우저는 http(s)를 사용한다. hosts는 웹 서버의 이름이나 도메인, IP를 사용하여 주소를 나타낸다. url-path는 웹 서버에서 지정한 루트 디렉토리부터 시작하여 웹 페이지, 이미지, 동영상 등이 위치한 경로와 파일명을 나타낸다.
URI(Uniform Resource Identifier)는 URL의 기본적인 요소인 scheme, hosts, url-path에 더해 query, bookmark를 포함한다. query란 웹 서버에 보내는 추가적인 질문을 의미한다. 위의 예제에서 ?q=JavaScript의 경우 JavaScript를 검색했을 때의 결과를 보여준다. 브라우저의 검색창을 클릭하면 나타나는 주소가 URI이고, URI는 URL을 포함하는 상위 개념이다.
부분 명칭 설명 file://, http://, https:// scheme 통신 프로토콜 127.0.0.1, www,google.com hosts 웹 페이지, 이미지, 동영상 등의 파일이 위치한 웹 서버, 도메인 또는 IP :80, :443, :3000 port 웹 서버에 접속하기 위한 통로 /search,
/Users/username/Desktop url-path 웹 서버의 루트 디렉토리로부터 웹 페이지, 이미지, 동영상 등의 파일이
위치까지의 경로 q=JavaScript query 웹 서버에 전달하는 추가 질문
IP와 포트
네트워크에 연결된 특정 PC의 주소를 나타내는 체계를 IP address(Internet Protocol address)라고 한다. 그리고 그 주소에 진입할 수 있는 정해진 통로를 포트(PORT)라고 한다.
1) IP
좀 더 상세하게 살펴보면 IP는 인터넷상에서 사용하는 주소체계를 의미한다. 기본적으로 인터넷에 연결된 모든 PC는 IP주소체계에 따라 네 덩이의 숫자로 구분된다. 이렇게 구분된 IP 주소체계를 IPv4라고 한다. IPv4는 각 덩어리마다 0부터 255까지 나타낼 수 있다. 2의 32승인 43억 개의 IP주소를 표현할 수 있는 것이다. 이 중에서 localhost와 127.0.0.1은 현재 사용 중인 로컬 PC를 지칭하고, 0.0.0.0과 255.255.255.255는 broadcast address로 로컬 네트워크에 접속된 모든 장치와 소통하는 주소이다. 만약 서버에서 접근 가능 IP주소를 broadcast address로 지정하면 모든 기기에서 서버로 접근할 수 있는 것이다. 최근에는 IPv6 역시 사용되는데, 인터넷이 보급된 초기와 달리 전 세계적으로 PC를 사용하면서 인터넷에 접속하다 보니 IPv4의 할당 한계 개수를 넘게 되었다. 이로 인해 16진법을 이용한 IPv6를 창안했고, 이는 2의 128승개까지 표현할 수 있다.
2) PORT
예를 들어 터미널에서 리액트를 실행하면 로컬 PC의 IP주소인 127.0.0.1 뒤에 :3000과 같은 숫자가 표현된다. 이 숫자는 IP주소가 가리키는 PC에 접속할 수 있는 통로(채널)를 의미한다. 이 포트는 중복해서 사용할 수 없기 때문에 해당 포트를 사용 중이면 다른 포트 번호가 사용된다. 포트 번호는 0부터 65535번까지 사용할 수 있고 그중에서 0 ~ 1024번까지의 포트번호는 주요 통신을 위한 규약에 따라 이미 정해져 있다.
:22 SSH :80 HTTP :443 HTTPS 그 외 https://en.wikipedia.org/wiki/List_of_TCP_and_UDP_port_numbers
도메인과 DNS
도메인은 웹 브라우저를 통해 특정 사이트를 진입할 때 IP주소를 대신하여 사용하는 주소이다. 이런 도메인 이름을 사용하면 IP주소와 달리 한눈에 파악하기 쉽다는 장점이 있다. IP를 이런 도메인으로 변환하는 것을 수행하는 시스템이 있는데, 이것이 DNS(Domain Name System)이다. 도메인 이름을 IP주소로 변환하거나 반대의 경우를 수행하는 데이터베이스 시스템이다. 예를 들어 브라우저창에 naver.com을 입력하면 DNS가 IP주소 (125.209.222.142)를 찾고 이 IP주소에 해당하는 웹 서버로 요청을 전달하여 클라이언트와 서버가 통신할 수 있도록 한다.
HTTP
HTTP(HyperText Transfer Protocol)는 HTML과 같은 문서를 전송하기 위한 응용계층 프로토콜이다. HTTP는 웹 브라우저와 웹 서버의 소통을 위해 개발되었다. HTTP는 독특한 특징이 있는데, 특정 상태를 유지하지 않는 특징이다. 이것을 무상태성이라고 한다. HTTP messages는 클라이언트와 서버에서 데이터가 교환되는 방식이다. HTTP messages에는 요청(Requests)와 응답(Responses)가 있다. HTTP messages는 몇 줄 텍스트 정보로 구성되는데, 개발자가 직접 작성할 경우는 드물다. 보통 구성 파일, API, 기타 인터페이스에서 HTTP messages를 자동으로 완성한다. 요청과 응답은 유사한 구조를 가진다. start line(status line)이 항상 첫 줄에 위치하는 것이나, 헤더와 본문을 구분하는 빈 줄이 있는 것이 그렇다. 또 start line(status line), headers, body로 구성된 기본 형식 역시 유사하다.
1) 요청(Requests)
start line
HTTP 요청은 클라이언트가 서버에 보내는 메시지이다. Start line에는 HTTP method, 요청 대상, HTTP 버전을 포함한다. HTTP 메소드는 수행할 작업(GET, PUT, POST 등)이나 방식 (HEAD or OPTIONS)을 설명한다.
둘째로 요청 대상으로 일반적으로 URL이나 URI, 프로토콜, 포트, 도메인 등이 온다. 요청 형식은 HTTP 메소드마다 다르게 온다. origin 형식의 경우 ?와 쿼리 문자열이 붙는 절대 경로인데, POST, GET, HEAD, OPTIONS 등의 메소드와 함께 사용한다. absolute 형식은 완전한 URL 형식으로 대부분 GET메소드와 함께 사용된다. authority 형식은 도메인과 포트 번호로 이루어진 URL의 authority componenet이다. HTTP 터널을 구축할 때 CONNECT와 함께 사용한다. asterisk 형식은 OPTIONS와 함께 별표(*) 하나로 서버 전체를 표현한다.
origin ?와 쿼리 문자열이 붙는 절대 경로 POST, GET, HEAD, OPTIONS absolute 완전한 URL 형식 GET authority 도메인과 포트번호로 이뤄진 URL CONNECT asterisk * OPTIONS
마지막으로 HTTP 버전은 버전에 따라 HTTP messages의 구조가 달라진다.
headers
요청의 Headers는 헤더 이름(대소문자 구분이 없는 문자열), 콜론(:), 값을 입력한다. 값은 헤더에 따라 다르다. 헤더 역시 여러 종류가 있는데, 메시지 전체에 적용되는 헤더로 body를 통해 전송되는 데이터와 관련이 없는 헤더인 General headers, 둘째로 fetch를 통해 가져올 리소스나 클라이언트 자체에 대한 자세한 정보를 포함하는 헤더인 Request headers, Request headers는 User-Agent, Accept-Type, Accept-Language와 같은 헤더의 경우 요청을 보다 구체화하고 Referer처럼 컨텍스트를 제공하거나 If-None과 같은 조건에 따라 제약을 추가할 수 있다. 셋째로 body에 담긴 리소스의 정보인 컨텐츠 길이, MIME타입 등을 포함하는 헤더인 Representation headers가 있다. Representation headers는 예전에는 Entity headers로 불렸다.
General headers 메시지 전체에 적용되는 헤더로 body를 통해 전송되는 데이터와는 관련이 없는 헤더 Request headers fetch를 통해 가져올 리소스나 클라이언트 자체에 대한 자세한 정보를 포함하는 헤더 Representation headers body에 담긴 리소스의 정보인 컨텐츠 길이, MIME타입 등을 포함하는 헤더
body
body는 HTTP messages 구조의 마지막에 위치한다. 모든 요청에 body가 필요한 것은 아니다. GET, HEAD, DELETE, OPTIONS처럼 서버에 리소스를 요청하는 경우에는 본문(body)이 필요하지 않다. 그러나 POST, PUT과 같은 일부 요청에서 데이터를 업데이트하기 위해 사용한다. body 역시 두 종류로 나뉘는데, 헤더 두 개 (Content-Type과 Content-Length)로 정의된 단일 파일로 구성된 Single-resource bodies(단일 - 리소스 본문)와 보통 HTML form과 관련 있는 여러 파트로 구성된 본문에서 각 파트마다 다른 정보를 지닌 Multiple-resource bodies(다중 - 리소스 본문)으로 구성된다.
2) 응답(Responses)
status line
응답의 첫 줄은 Status line이라고 부르며, 현재 프로토콜의 버전, 상태 코드(요청의 결과), 상태 텍스트(상태 코드에 대한 설명)를 포함한다.
headers
응답에 들어가는 HTTP headers는 요청 헤더와 동일한 구조를 가진다.
body
응답의 본문은 HTTP messages 구조의 마지막에 위치한다. 201, 204와 같은 상태 코드를 가지는 응답에는 본문이 필요하지 않다. 응답의 body 역시 두 종류로 나뉜다. Single-resource bodies(단일 - 리소스 본문)은 길이가 알려진 경우 두 개의 헤더(Content-Type, Content-Length)로 정의하고 길이를 모르는 단일 파일로 구성된 경우 Transfer-Encoding이 chunked로 설정되어 있어서, 파일이 chunk로 나뉘어 인코딩 되어있다. Multiple-resource bodies(다중 - 리소스 본문)은 서로 다른 정보를 담고 있는 body이다.
stateless
무상태성이란 말 그대로 상태를 가지지 않았다는 뜻이다. HTTP로 클라이언트와 서버가 통신을 주고받는 과정에서, HTTP가 클라이언트나 서버의 상태를 확인하지 않는다. 여러 기록이나 로그를 클라이언트에서 발생시켰다고 해도 이런 모든 상태를 HTTP 통신이 추적하지 않는 것이다. 이로 인해 상태를 저장해야 하는 경우 쿠키-세션이나 API 등을 통해 상태를 확인해야 한다. 이것이 HTTP 무상태성이다.
HTTP의 상태 코드
HTTP의 상태 코드는 https:/developer.mozilla.org/ko/docs/Web/HTTP/Status 여기서 확인할 수 있다. 필요에 의해 찾아서 확인하는 것으로 충분하다.
AJAX
AJAX란 Asynchronous JavaScript And XMLHttpRequest의 약자로 JavaScript, DOM, Fetch, XMLHttpRequest, HTML 등의 다양한 기술을 사용하는 웹 개발 기법이다. AJAX의 가장 큰 특징은 웹페이지에 필요한 부분에 필요한 데이터만 비동기적으로 화면에 그려낼 수 있다는 것이다. 대표적으로 검색창이 그렇다. 검색창에 검색할 때 추천 검색어를 유동적으로 보여주는데, 이때 비동기적으로 받아와 렌더링이 된다. 여기 AJAX가 사용된 것이다. 또 다른 예로 홈페이지에서 스크롤을 통해 계속해서 새로운 데이터를 보여주는 경우가 있다. 이것을 무한 스크롤이라고 한다. 무한 스크롤이 발생할 때마다 Fetch를 통해 데이터를 가져와서 업데이트하고 렌더링 하는 것이다. 쿠팡의 앱이 이런 기술을 적용했음을 알 수 있다.
AJAX를 구성하는 핵심 기술은 JavaScript와 DOM, 그리고 Fetch이다. Fetch를 사용하면 전통적인 웹 앱과 다르게 페이지를 이동하지 않아도 서버로부터 필요한 데이터를 받아 올 수 있다. 그리고 Fetch는 사용자가 현재 페이지에서 작업을 하는 동안 서버와 통신할 수 있도록 한다. 왜냐하면 비동기 작업이기 때문이다. 또 자바스크립트에서 DOM을 사용해 조작할 수 있기 때문에, Fetch를 통해 전체 페이지가 아닌 필요한 데이터만 가져와 DOM에 적용시켜 새로운 페이지로 이동하지 않고 기존 페이지에서 필요한 부분만 변경할 수 있다.
AJAX 장점 AJAX 단점 서버에서 HTML을 완성하여 보내주지 않아도 웹페이지를 만들 수 있다. 필요한 데이터를 비동기적으로 가져와 브라우저에서 화면의 일부만 업데이트하여 렌더링할 수 있는 것이다. SEO(Search Engine Optimization)에 불리하다. AJAX는 한 번 받은 HTML을 렌더링 한 후 서버에서 비동기적으로 필요한 데이터를 가지고 오기 때문에 처음 받는 HMTL 파일에 데이터를 채우기 위한 틀만 작성된 경우가 많다. 그래서 검색 사이트에서는 적합하지 않다. XHR이 표준화 되면서부터 브라우저에 상관 없이 AJAX를 사용할 수 있게 되었다. 뒤로가기 버튼에 문제가 있다. AJAX는 이전 상태를 기억하지 않기 때문에 뒤로가기 버튼을 사용하면 의도한대로 동작하지 않는다. 유저 중심적으로 필요한 일부분만 렌더링하기 때문에 빠르고 더 많은 상호작용이 가능한 앱을 만들 수 있다. AJAX에서 필요한 데이터를 텍스트 형태(JSON, XML 등)를 보내면 되기 때문에 비교적 데이터의 크기가 작다. 이로인해 더 작은 대역폭을 사용할 수 있따.
SSR과 CSR
SSR은 Server Side Rendering의 줄임말이다. 웹 페이지를 브라우저가 아닌 서버에서 렌더링 하는 방법을 말한다. 브라우저가 서버의 URI로 GET 요청을 보내면 서버는 정해진 웹 페이지 파일을 브라우저에 전송한다. 그리고 웹 페이지가 브라우저에 도착하면 완전히 렌더링 된다. 웹 페이지의 내용에 데이터베이스의 데이터가 필요한 경우, 서버는 데이터베이스의 데이터를 불러온 다음 웹 페이지를 완전히 렌더링 된 페이지로 변환한 후에 브라우저에 응답을 보낸다.
CSR은 Client Side Rendering의 줄임말이다. SSR의 반대의 개념인데, CSR은 클라이언트에서 페이지를 렌더링 하는 방식이다. 브라우저의 요청을 서버로 보내면 서버는 웹 페이지를 렌더링 하는 대신 웹 페이지의 골격이 될 단일 페이지를 클라이언트에 보낸다. 그와 함께 서버는 JavaScript파일을 보낸다. 클라이언트가 웹 페이지를 받으면 함께 전달된 JavaScript파일로 브라우저에서 웹 페이지를 완전히 렌더링 된 페이지로 바꾼다. 만약 필요한 데이터가 데이터베이스에 있는 경우에는 브라우저는 데이터베이스에 저장된 데이터를 가져와서 웹 페이지에 렌더링 해야 한다. 그래서 여기에 API가 사용된다. 웹 페이지를 렌더링 하는 데에 필요한 데이터를 API로 해결하는 것이다.
CSR과 SSR의 주요 차이는 페이지가 렌더링 되는 위치이다. SSR은 서버에서 페이지를 렌더링하고 CSR은 브라우저(클라이언트)에서 페이지를 렌더링 한다. 브라우저는 사용자가 다른 경로를 요청할 때마다 페이지를 새로고침 하지 않고, 동적으로 라우팅을 관리하는 것이다.
SEO(Search Engine Optimization)이 우선순위인 경우와 첫 화면의 렌더링이 빠르게 필요한 경우, 웹 페이지가 사용자와 상호작용이 적은 경우 SSR을 주로 사용한다. 반면에 SEO가 우선순위가 아닌 경우와 사이트에 상호 작용이 많은 경우, 웹 앱을 제작하는 경우 더 강력한 사용자 경험을 제공하기 위해 CSR을 사용한다.
CORS
CORS는 Cross-Origin Resource의 약자이다. 서로 다른 origin 간의 리소스를 공유하는 개념이다. 브라우저가 자발적으로 브라우저를 사용하는 유저들을 보호하는 정책이라고 할 수 있다. 즉, 브라우저의 자발적인 보안정책이다. 추가 HTTP 헤더를 사용하는 경우 simple requests가 아닐 때 기존에 사용하던 웹 앱에 추가되는 출처의 자원에 접근할 것인지 권한을 브라우저에 알려주는 형식으로 진행된다.
1) simple requests
simple requests는 CORS preflight를 트리거하지 않는 요청을 말한다. 그냥 단순 요청이다. simple requests의 조건은 GET, HEAD, POST 메소드를 사용하는 경우이면서, header에 자동적으로 생성되는 기본적인 요소를 제외한 특정 내용이 추가되지 않는 경우이면서 application/x-www-firn-urlencoded, multipart/form-data, text/plain의 타입 중 하나일 때이다. 위의 모든 조건을 통과할 때는 simple requests를 실행한다. 먼저 클라이언트와 서버 간의 통신을 하고 나서 CORS 헤더를 사용하여 권한을 처리하는 방식이다.
2) preflighted requests
preflighted requests는 위와 다르게 특정 요청을 보내면 그전에 OPTIONS 메소드 요청이 먼저 이루어지고 특정 요청이 이루어지는 방식이다. 미리 OPTIONS 메소드를 통해 다른 도메인의 리소스로 HTTP 요청을 보내 실제 요청이 전송하기에 안전한지 확인하는 것이다. PUT, DELETE, CONNECT, OPTIONS, TRACE, PATCH 메소드를 사용하는 경우이거나 header에 자동적으로 생성되는 기본적인 요소를 제외한 다른 특정 내용이 추가되는 경우이거나 application/x-www-firn-unlencoded, multipart/form-data, text/plain 중 하나의 타입이 아닌 경우(JSON 등) preflifhted requests가 실행된다.
느낀 점
당장 네트워크를 통해 데이터를 간단히 주고받기 위해 알아야 하는 네트워크 지식이 이 정도라는 것에 혀를 내둘렀다. 역시 IT의 공부는 밑 빠진 독에 물을 붓는 듯하다. 앞으로 필수적으로 해가야 할 네트워크 지식 공부뿐만 아니라 끊임없이 쏟아져 나오는 새로운 지식까지 차근차근 학습해야겠다. 하면 할수록 느끼는 것은 이 공부는 기존의 것을 완벽히 소화한다기보다 적응하는 것에 가깝다는 것이다. 지금 배우는 것이 언제 낡은 것이 되어 버려질지 알 수 없고, 또 기존에 있는 것만 해도 너무 방대하기 때문에 소화하려다 체하기 딱 십상이다. 결국 쏟아져 나오는 더 진보된 기술을 얼마나 빨리 적응하고 사용하는가가 관건이라 느낀다. 여기에 초점을 두고 기본기를 쌓아가고자 한다.
공유하기 글 요소 저작자표시
from http://anhyang.tistory.com/28 by ccl(A) rewrite - 2021-11-03 15:27:39