캐시 기본 동작 다들 웹 페이지를 새로고침을 하거나 잠시 다른곳을 다녀올때? 컴퓨터가 내 방문 경로를 잘 알고있구나 라는 느낌이들 정도로 빠르게 로드된다. 다만 어떤 페이지를 처음 방문할 때는 역시 컴퓨터도 초행길이라 그런지 조금 느릴 수 밖에 없다고 그냥 당연하게 생각하고 있었다. 하지만 이런 차이를 느끼게 하는 것이 바로 캐시라는 것이다. 내가 데이터를 한번 요청했다치자, 다음번에도 똑같은 데이터를 요청할땐 이제 웹 브라우저 자체적으로 쿠키저장소가 있듯이 캐시저장소도 있다. 그 캐시저장소에 데이터가 유효한 채로 저장되어있다면 굳이 서버에 요청하지않고 브라우저에서 꺼내쓰는 메커니즘이다. 이를 통해 캐시 유효 시간동안 네트워크를 사용하지 않아도 된다. 비싼 네트워크 사용량을 줄일 수 있다. 브라우저 로딩 속도가 매우 빨라진다. 사용자로 하여금 굉장히 빠른 경험을 제공할 수 있다. 그러나 캐시의 시간이 초과되면..? 그땐, 네트워크 다운로드를 감수하

한 2주 쉬었나? 회사 보안감사에 내 자리가 인터넷이 안되는 곳으로 옮겨지면서 HTTP step을 진행하지 못하고 있었다...ㅋㅋㅋ 물론 지금도 인터넷이 연결된 자리에 오랜만에 앉아서 시간 짬내서 쓰는것이다! HTTP 헤더 우선, HTTP 헤더는 HTTP 전송에 필요한 모든 부가적인 정보가 담긴다. 예를 들어, 메시지 바디의 내용, 크기, 그리고 압축과 인증, 서버 정보, 캐시 관리 정보 등등... 자세히 알아보자! 표현 헤더 리소스를 어떤 형식으로 전송할 것인지 예를 들어, 회원이라는 리소스가 있다면 html로 전송할 것인지 json으로 전송할 것인지에 대한 명세다. Content-Type : 표현 데이터의 형식 (text/html, application/json & charset=UTF-8) Content-Encoding : 표현 데이터의 압축 방식 (gzip, deflate,identity) Content-Language : 표현 데이터의 자연

HTTP 상태코드란?? 클라이언트가 서버로 요청을 보내면 요청이 잘 처리가 됐는지 문제가 있는지 서버에서 response를 보낼때 알려주는 기능이다. 크게 다섯가지로 나뉜다 1xx (Informational) - 요청이 수신되어 처리중 (안씀) 2xx (Successful) - 요청이 정상적으로 처리됨 3xx (Redirection) - 요청을 완료하려면 추가 행동이 필요함 4xx (Client Error) - 클라이언트 오류, 잘못된 문법등으로 서버가 요청을 수행할 수 없음 5xx (Server Error) - 서버측 오류, 서버가 정상적으로 요청을 처리하지 못한다. 음.. 지금 당장에도 내가 이클립스 기반 Spring MVC 프로젝트 환경 구축을 거의 완료하긴했는데, 잘 뜨던 home.jsp가 갑자기 ![](https://velog.velcdn.com/images/qodlstjd12/post/13141f0b-8780-4ae1-be97-78dcc216e

HTTP 메소드 웹의 요청과 응답에 대한 흐름을 파악했다면, 개발에 있어서 가장 중요한 상식중 첫 번째라고 개인적으로 생각한다. 근데 웹 개발을 한 번이라도 해봤다면? GET, POST에 대한 것은 들어보지 못했을리가 없다고 생각한다. 그리고 상식이라고 표현한만큼 개념적으로 크게 어려운건 없다 ㅋㅋㅋ Django로 홈페이지를 제작할 당시, 개발 방식이 views.py에서 함수마다 이런식으로 GET과 POST일때를 나눠서 코딩해줬었던 기억이 난다. Spring에서는 컨트롤러에서 @GetMapping @PostMapping 으로 url을 분리해줬던 것으로 기억한다. 어쨌든 오늘은 HTTP의 주요 메소드 GET,POST와 DELETE, PATCH, PUT에 대해서 글을 써보도록 하겠다! GET GET은 "얻다"라는 단어 뜻으로, 클라이언트에서 GET 요청이 오면 어떤 리소스를 달라는 뜻이다. 그 리소스는 주로 HTML일 것으로 생각한다. 그래서 GET 요청은 그

HTTP HTTP란 HyperText Transfer Protocol 이고, 초기에는 문서간의 링크를 통해서 연결할 수 있는 html을 전송하는 것이 시작이었는데, 지금은 모든 형태의 데이터를 전송할 수 있다. HTTP는 여러 버전이 있는데, 지금 가장 많이 쓰이는 것은 HTTP 1.1 버전이다. HTTP 1.1은 기본적으로 TCP기반이고, 현재 UDP 기반의 HTTP 3이 개발되고 있는데 UDP의 특성을 공부한 이후라서, HTTP 3버전이 굉장히 기대된다 ㅋㅋ (얼마나 빠를지) HTTP의 특징 클라이언트 서버 구조 무상태 프로토콜(Stateless) 지향 비연결성 HTTP 메세지를 통해 통신을 한다. 단순하고 확장가능함 밑에서부터 하나씩 살펴보도록 하겠다! 클라이언트 서버 구조 ![](https://velog.velcdn.com/images/qodlstjd12/post/92614481-8375-40e5-9b27-dbe474f088e1/im

URI 나는 평소에 남들처럼 URL만 알았지 URI라는게 있는지 처음 알았다. 심지어 URI는 URL을 포함하는 개념이었다. > URI (Uniform Resource Identifier) • Uniform: 리소스 식별하는 통일된 방식 • Resource: 자원, URI로 식별할 수 있는 모든 것(제한 없음) • Identifier: 다른 항목과 구분하는데 필요한 정보 라고 한다! 이러한 URI는 한마디로 자원(리소스)를 식별하는 통합된 방법인데, 크게 두 가지로 나뉜다. URI 1-1. URL(Uniform Resource Locator) : 리소스가 있는 위치를 지정 1-2. URN(Uniform Resource Name) : 리소스에 이름을 지정 URN은 잘 안쓰고 다들 아는 URL이 사람들이 보통 아는 것이다. 다이어그램으로 표현하자면 이렇게 된다. ![](https://velog.velcdn

글을 쓰게 된 동기 Spring을 공부하다보면 나도 모르게 Django와 비교하게 된다. MTV 패턴을 떠올리며 MVC를 학습하려하고, Spring을 통해 구현되는 CRUD를 Django때와 비교하게 되는 등등,,, 그리고 한 가지 또 깨닫게 된게 있다면, Django 조차 겉핥기만 해본 나의 착각이겠지만! 간단한 홈페이지를 제작하는데 있어서는 확실히 Django가 Spring에 비해 HTTP 지식이 덜 요구되었던 것 같다. Spring을 공부하면서 김영한 강사님을 따라 클라이언트에서 온 요청을 뜯어보았는데, 클라이언트에서 서버에 어떻게, 어떤 데이터를 가지고 도착하는지, 그 방식은 어떠한지에 대해 더욱 관심을 갖게 되었다. 이를 통해, GET과 POST를 제외한 어떤 HTTP 지식도 없었던 내가 Django를 통해 2가지의 웹 프로젝트를 진행했는지가 신기하게 느껴질 정도로 HTTP 지식은 웹 개발자에게 있어서 필수 지식임을 깨달았다. 그리고 HTTP에 대한