44,000원
다른 수강생들이 자주 물어보는 질문이 궁금하신가요?
- 미해결모든 개발자를 위한 HTTP 웹 기본 지식
HTTP method 약속
안녕하세요, 영한님 좋은 강의 감사합니다. 들을수록 질문이 늘어가네요..지금 설명해주시는 http method(get, post, patch, put) 기능들은 관례적으로 그렇게 사용된다는 걸 설명해주시는 건지요? 예를 들어, 좋은 방법은 아니겠지만, 스프링에서 PostMapping으로 받더라도 그에 따라 백엔드 단에서 어떻게 구현할지는 오로지 백엔드 개발자에게 달려있는 거 같아서요. http method는 관례적으로 이렇게 사용되니, 클라이언트 개발자와 백엔드 개발자가 소통할 때 기존에 약속된 기능 스펙대로 백엔드 단에서 구현되는 게 바람직하다 정도로 이해하면 될까요?
- 미해결모든 개발자를 위한 HTTP 웹 기본 지식
리소스 명사 네이밍
안녕하세요. 해당 강의 질문 댓글 '좋아요' 기능을 보면서 궁금한 점이 생겼습니다. 1. '좋아요'를 눌렀을 때, 단순하게 생각해보면 아래와 같이 설계할 수 있을 것 같습니다. 영한님이 강의에서 동사 네이밍은 최대한 지양하라고 하셨는데, 저에게 가장 직관적으로 와닿는 건 like라는 단어인데 like는 동사이니 heart 라는 단어를 사용하는 게 좋을까요? 강의/강의idx/댓글/댓글idx POST /lecture/{1}/comment/{12}/likePOST /lecture/{1}/comment/{12}/heart 2. 그리고 현재 강좌 api가 https://www.inflearn.com/course/http-%EC%9B%B9-%EB%84%A4%ED%8A%B8%EC%9B%8C%ED%81%AC/lecture/61365?speed=1.25&tab=community 인데, 왜 courses가 아닌 course, lecture는 lectures가 아닌 lecture로 설계가 된 건지 궁금합니다!
- 미해결모든 개발자를 위한 HTTP 웹 기본 지식
GET 메서드 body
안녕하세요. 영한님이 말씀하신 부분 중에 이해가 잘 가지 않는 점이 있는데요. GET 메서드를 사용할 때 body에 데이터를 넣지 말라고 하시고 그 이유로, 지원하지 않는 서버가 있다라고 하신 말씀이 잘 이해가 되지 않습니다. 여기서 말하는 서버는 스프링 같은 BE Language 단에서 GET에서 body 데이터를 받도록 구현이 안 됐다는 의미일까요?
- 미해결모든 개발자를 위한 HTTP 웹 기본 지식
리소스 복수명사
삭제된 글입니다
- 미해결모든 개발자를 위한 HTTP 웹 기본 지식
http통신을 socket 통신이라고 할 수 있나요?
영한님 강의를 통해서 열심히 웹공부 중인 학생입니다. 늘 감사하게 강의를 듣고 있습니다! '웹 브라우저 요청흐름' 강의를 통해서, 실시간 기술이 필요한 게임같은 경우를 제외하고 일반적인 요청-응답 방식으로 http통신을 이용한다는 것을 알 수 있었습니다. http 통신 과정에서 os에 내장되어있는 socket 라이브러리를 통해 TCP/IP 프로토콜로 서버와 커넥션(3-way handshaking)하게끔 한다고 하셨는데, 이 부분에서 클라이언트가 TCP 프로토콜을 직접 사용하지 않고, socket 라이브러리가 대행해준 것 (= 간접적으로 사용)이라고 이해하였습니다. 제가 여쭤보고 싶은건, 보통 http 통신과 실시간 socket 통신으로 구분 짓는 경우가 있는데, http 통신도 socket 라이브러리를 이용한다면 큰 범주로 소켓을 사용한 socket 통신이라고 말할 수 있는 것인가요? 그렇게 된다면 socket 통신이 TCP 프로토콜을 직접 사용하는 것이니, http 통신이 TCP 프로토콜을 간접적으로 사용한다는 부분이 이해가 되지 않습니다..! http통신의"소켓" 라이브러리와 실시간 "소켓"통신에서의 소켓이 다른 맥락인것인지.. 감사합니다!
- 해결됨모든 개발자를 위한 HTTP 웹 기본 지식
마지막에 나온 잘 알려진 port번호는 컴퓨터 모두에게 해당하는 건가요?
살짝 헷갈려서 질문드립니다. 제가 웹 브라우저를 쓰면서 어떤 서버에 웹페이지를 요청하면 저도 80쓰고 서버도 80포트를 쓰는건가요?
- 미해결모든 개발자를 위한 HTTP 웹 기본 지식
근데 목적지 포트와 목적지 IP는 어떻게 아는거죠?
서버에서 응답을 넘겨줄 때는 패킷에 출발지 포트, 출발지 아이피가 적혀 있어서 가능하다는 것을 알겠습니다. 하지만 클라이언트에서 서버로 데이터 전송 시 아이피와 포트번호를 어떻게 알고 보내는 건가요? 아이피는 https://www.google.com << 이 도메인 이름인건가요? 그렇다면 포트는 어떻게 알고 보내죠..? ----------------------------------------------- 추가적으로 질문을 하면서 갑자기 또 궁금한게 생겼습니다. 여기서 말하는 클라이언트와 서버라는게 이해가 잘 가지 않습니다. 예를들어, 프로그램을 짠다고 했을때 제가 아는건 html,css,javascript의 front 쪽에서 Java, oracle 등 back으로 데이터를 넘겨주고, 그 데이터를 처리한 값을 다시 front로 넘겨주는 걸로 알고 있습니다. 이때, front가 클라이언트, back이 서버가 되는게 아닌가요..? 근데 마치 예시에서는 클라이언트가 이 컴퓨터, 서버는 저 컴퓨터 같은데 이런 개념이 잡히지가 않네요. 혹시 이부분에 대해 도움 받을 수 있을까요?
- 미해결모든 개발자를 위한 HTTP 웹 기본 지식
개발자님 질문이 있습니다.. !
안녕하세요. 개발자님. 실천은 잘 못하지만 머리로? 천성?은 학자형 스타일 같은 학생입니다.. ㅎㅎ 로드맵 추천을 이전편에도 봤고, 이번편에도 봤는데 해당 영상들은 spring mvc 활용 강의가 나오기 전이고 지금은 1, 2편이 모두 나와있는 상태인데 어떤 강의부터 보는게 좋을까 궁금합니다.. ㅋㅋㅋㅋ 이미 추천을 해주셨는데 재추천을 바라는게 웃기지만 현재 스프링 강의가 2편 더 나와있는 관계로 어떤 테크트리를 타야할지 고민이 됩니다.. 사실 이거보고 저거보는거나 저거보고 이거보는거나 비슷할거 같기는 하지만요.. ㅋㅋㅋ 현재 스프링 강의는 나온 것 까지 구매한 상태이고 JPA 강의는 아직 구매하진 않았고, 강의 볼 때 구매하려고 합니다. 그리고 입문, 기본편이 잘 이해가 되지 않았는데 한번 다시 보고 다음 강의를 수강하는 것도 어떤지 알고 싶습니다. 제가 결정할 문제들이긴 하지만 괜히 스승님의 조언을 얻고 싶어서 이렇게 글 남깁니다.. ㅋㅋ 여담이지만 늦은 나이에 회사에 들어가서 생각과는 안맞아서 3개월 다니고 나왔는데.. 나오면 공부 열심히 할줄 알았는데, 시간은 많은데 그건 또 아닌거 같네요.. ㅋㅋ 빨리 개발자님의 강의를 들으며 공부하고 부족한 부분 메꿔서 준비해야겠습니다.. 저는 야생형이 될수 없나봐요.. 여담으로 30% 묶음 할인 이런 것은 개발자님이 진행 하시는 건가요? 아니면 인프런 내에서 진행하는 건가요. 할인 안받고 봐야하는 최고의 강의이지만 할인 예정이 있으면 그에 맞춰서 사는게 좋을거 같아서요.. (빈털털이..) 늘 고생하시고 좋은 강의 찍어주시고 답변까지 해주시고 많이 감사합니다. 항상 건강하시고 행복한 일 많으셨으면 좋겠습니다. 다음 강의에서 뵙겠습니다 ㅎㅎ
- 미해결모든 개발자를 위한 HTTP 웹 기본 지식
프록시 캐시 서버에 관련해 질문 있습니다.
안녕하세요. 개발자님. 만약에 no-cache, must-revalidate 등을 쓴다면 프록시 서버를 거쳐도 무조건 원 서버에 확인이 필요하니까 클라이언트의 웹 브라우저와 원서버가 직접 연결이 된 경우보다 프록시 서버가 있는 쪽이 오히려 더 비효율적일 수도 있을거 같네요. 이 부분에 대해서 궁금합니다. 감사합니다.
- 미해결모든 개발자를 위한 HTTP 웹 기본 지식
프록시 캐시 설명부분에서 질문 있습니다.
안녕하세요. 개발자님. 수업을 듣던 중 모호한 부분이 있어서 질문 남깁니다. 수업 중 프록시 캐시라는게 없을 시 0.5ms의 시간이 걸린다고 가정했습니다. 또 프록시 서버가 있을 경우 프록시 각각 클라이언트가 프록시 서버에 접근하는 시간이 0.1ms이고 프록시 서버가 원 서버에 접속하는 시간이 0.4ms라고 가정 했습니다. 1. 이말은 프록시 캐시 서버를 도입하게 된다면, 프록시 캐시 서버가 먼저 원서버에서 캐시를 받아서 보관해두고, 클라이언트는 해당 데이터를 원서버가 아닌 프록시 서버에서 데이터를 받아오기 때문에 0.1ms의 시간만 소요해서 보다 빠르고 효율적이다. 이렇게 이해해도 되는것인지 알고 싶습니다. 2. 만약 1번에서 이해한 부분이 맞다면, 클라이언트의 브라우저에 캐시로 보관하는건 데이터를 요청 시 시간 소요가 훨씬 더 적은 가장 빠른 방법일 것 같은데, 굳이 프록시 서버에 캐시에 보관해두었다가 데이터를 내려받는게 좀 이해가 안갑니다. 이런 맥락에서 프록시 캐시 서버의 용도나 장점이 잘 이해가 가지 않는 부분도 있습니다. 3. 2번과 비슷한 질문인데 그렇다면 private(클라이언트 브라우저), public(프록시 캐시 서버) 캐시 서버마다 각각 다른 데이터를 저장해 두는 것 같은데, private 클라이언트 브라우저 캐시에 사용자 민감한 정보 뿐만이 아니라 다른 정보들도 넣어두면 되는 것 아닌가요? 굳이 public 프록시 캐시 서버에 보관하는 이유를 모르겠습니다. 또 사견이지만 민감한 정보들은 private 클라이언트 브라우저에 캐시로 저장하면 안될거 같은데 강의 내용에는 그렇게 되어 있어서 이부분도 궁금합니다. 4. 클라이언트 브라우저 캐시에 사용자 정보 등 민감한 정보를 보관하게 된다면 보안상 문제는 안생기나요? 감사합니다. 오늘도 좋은하루 되시길 바랍니다.
- 미해결모든 개발자를 위한 HTTP 웹 기본 지식
멱등이 잘 이해가 가지 않습니다.
안녕하세요. 개발자님. HTTP 메서드의 속성 중 안전은 몇번을 실행하던 관계 없이 리소스가 변하지 않는 것, 멱등은 몇번을 실행하던 결과가 같아야 한다는 것, 캐시가능은 캐시해서 사용해도 되는 여부라고 강의에서 들었습니다. 그런데 멱등의 경우 '멱등하다'라는게 GET, PUT, DELETE 만 적용이 된다고 하셨습니다. POST와 PATCH는 안된다고 하셨는데, 이 부분이 이해가 가지 않습니다. GET은 조회니 당연히 결과가 같을 것입니다. 하지만 PUT의 경우 아래 질문 글의 PATCH와 같이 + 10을 하는 것으로 구현한다면 계속 + 10된 값으로 덮어 씌워지니까 전체가 덮어씌워지는지, 일부만 수정되는지의 차이이지 동일 실행에 같은 값이 나온다고 말할 수 없는 것 같아서 이해가 가지 않습니다. PUT이 어떻게 멱등하고 PATCH는 멱등하지 않은지 궁금합니다. DELETE의 경우 삭제니까 수행 횟수에 상관 없이 결과는 같을거라고 예상이 됩니다. 비슷한 맥락으로 비교 대상은 없지만 POST가 멱등하지 않은 이유도 잘 이해가 가지 않아서 질문 남깁니다. 감사합니다. 좋은하루 보내시길 바랍니다!
- 미해결모든 개발자를 위한 HTTP 웹 기본 지식
304로 응답하면 Content-Length는 0이 돼야 하지 않을까요?
Content-Length는 HTTP Message Body의 데이터 크기의 바이트 수를 명시하는 헤더입니다. 해당 강의 6:55 쯤에 나오는 자료에 보면, response message에 304가 떨어져서 Body가 비어있음에도 Content-Length는 여전히 큰 값을 가지네요. 이 부분이 조금 난해하네요. 감사합니다 :)
- 해결됨모든 개발자를 위한 HTTP 웹 기본 지식
노드가 뭔가요?
안녕하세요. 강사님 노드가 컴퓨터 한 대 인가요? 인터넷 개념이 전혀 없어서 클라이언트에서 서버로 요청을 보내면 요청이 바로 서버로 날라간다고 생각했는데 중간에 노드를 탄다고 해서 헷갈립니다. 노드는 다른 컴퓨터라고 생각하면 될까요?
- 미해결모든 개발자를 위한 HTTP 웹 기본 지식
안녕하세요. 이번강의 정리중에 궁금증이 있어서 질문드립니다.
안녕하세요. 개발자님 아래 질문에서도 확인했는데, 그 글과 답변을 보고도 모호해서 저도 비슷한 내용으로 질문 남깁니다. 1. 현재 RFC723x HTTP에서는 헤더로 - General 헤더 : 메시지 전체에 적용되는 정보, 예) Connection: close - Reuquest 헤더 : 요청을 보낼때 포함하는 정보, 예) User-Agent: Mozilla/5.0 (Macintosh; ..) - Response 헤더 : 응답에 들어가는 정보, 예) Server: Apache - Representation 헤더 : 표현 데이터(바디) 정보 이렇게 4가지로 쓰고, 이렇게 정리하면 되는게 맞나요? 이전 버전이 폐기되고 723x를 설명 해주실때, 바로 BODY 부분으로 넘어가신거 같아서 약간 정리가 안됩니다. 2. 이전 버전과 차이가 entity -> representation으로 명칭이 바뀐거 같은데, HTTP BODY에 대한 설명은 거의 같은 것 같아 보입니다. 말 그대로 명칭만 바뀐 것인지 어떤게 중점적으로 바뀐 것인지 궁금합니다. 3. HTTP 전송 시 헤더 + 바디로 보내는 것 같은데, 요청시 request Header + (general헤더 + representation 헤더 + message body), 응답 시 response Header + (general헤더 + representation 헤더 + message body) 이렇게 보내는 건가요..? 모든게 요청 아니면 응답 같은데, request header 나 response 헤더는 요청이냐 응답이냐에 따라 필수적으로 포함되는 것 같고, representation header와 general header는 message body가 있느냐, 요청/응답과 상관 없이 보낼 정보가 있느냐에 따라 포함될 수도 있고 포함되지 않을 수도 있을 것 같다 정도로 이해했는데 잘 이해한게 맞는건지 궁금합니다. 날도 많이 덥고 코로나도 심한데 건강 유의하시길 바라고 늘 좋은 일 많으시길 바랍니다!
- 해결됨모든 개발자를 위한 HTTP 웹 기본 지식
Socket 방식으로 통신하는게 TCP 프로토콜을 직접 사용하는 경우인가요??
안녕하세요, 강사님! 강의를 듣다가 궁금한 게 생겨서 질문드립니다. 1분 14초에서 보면 실무에서 통신할 때 TCP 프로토콜을 직접 사용해서 통신하는 경우가 없다. 게임 서버 같은 경우에나 그런 방식을 사용한다고 하셨습니다. 두 방식의 장단점이 뭐가 있을지 궁금해서 인터넷을 찾아보는데, HTTP 방식과 Socket 방식의 장단점을 비교한 글들이 많더라구요!! Socket 방식은 온라인 게임 등에 사용된다고 하던데, 혹시 Socket 방식으로 통신하는게 TCP 프로토콜을 직접 사용하는 경우인가요?? 강의 정말 재밌게 듣고 있고, 덕분에 공부하는 게 재밌습니다! 학자형으로 공부하는 스타일이라 지치고 이해가 안되는 경험들이 많은데, 강사님 덕분에 많은 걸 배웁니다. 감사합니다 :)
- 미해결모든 개발자를 위한 HTTP 웹 기본 지식
API 서버와 프론트엔드 서버 분리 관련
안녕하세요 이 곳에 맞는 질문일지 모르겠지만 지푸라기라도 잡는 심정으로 질문남겨봅니다ㅜ 혹시 이 질문게시판 성격과 맞지 않는다 판단되시면 답변 안해주셔도 됩니다! 현재 이커머스 편집샵을 운영하는 초기 스타트업에서 1인 개발자로 일하고 있는 2년차 백엔드 주니어입니다. 개발자로서 비즈니스 차원에서의 방안을 내야하는 상황이라 이렇게 글남깁니다. <상황> 1. 새 브랜드(기존 브랜드와 느낌이 완전 상이한) 입점 관련하여 운영팀에서 2개 웹사이트 운영하자는 방안을 내놓음 2. 코드는 루비온레일즈로 구성된 모놀리식 구조입니다. <질문> 1. 현재의 구조를 루비온레일즈 API 서버 1개 + Vus.js 프론트엔드 서버 2개 로 운영하는 방안을 제안해보고자 합니다(웹사이트 분위기나 톤은 다르지만 사용하는 데이터는 결국 같을것같습니다). 각 프론트엔드 서버로 도메인, 서브도메인을 연결하고자 하구요. 이러한 접근방식이 맞는 방법인지 궁금합니다 2. 1번이 불가능한 옵션이라면, 2개의 웹사이트를 각각 구축하는 것이 나을지, 현재 웹사이트에 UX/UI적으로 풀어내는 것이 맞을지 궁금합니다. 뜬금없는 질문일지 모르겠으나 어떻게든 헤쳐나가고자 이렇게 질문남겨봅니다ㅜ 답변 주시면 정말 감사하겠습니다!!
- 미해결모든 개발자를 위한 HTTP 웹 기본 지식
Http 메서드 중 Post가 잘 이해가 가지 않습니다.
Post가 요청 데이터 처리를 한다고 하셨는데 이 데이터 처리가 무엇을 의미하는지 잘 모르겠습니다 .. Get은 데이터를 보여주고, 다른 메서드는 수정 및 삭제 등등 하는데 Post는 처리한다는게 정확하게 무슨 의미인지 잘 모르겠습니다.
- 미해결모든 개발자를 위한 HTTP 웹 기본 지식
8분 13초쯤에 질문있습니다.
1. 일단 a -> b 로 데이터를 전송할때 인터넷을 활용하고, 수많은 노드(=서버)를 거쳐서 전달되는걸로 이해했는데 맞나요? 2. 8분 13초쯤에 논리적 연결이지 물리적 연결을 보장해주지 않는다는 것을 말씀하시면서 그 사이의 서버들이 연결되어 있는지는모른다고 표현하셨는데, ack을주고 받는 과정에 3번동안 주고 받았다면 a->b 로 가는 노드들이 적어도 하나이상은 연결되어 있다는거 아닌가요? 만약 그게 아니라면 무슨 연결을 체크한 것인지 이해가 잘 가지 않습니다. 단순히 서버가 존재하는지 여부인가요? 그걸 체크했다고 하더라도 오는길, 가는길이 있을수 밖에 없다고 느껴집니다. 3. 2번이 맞다면 물리적 연결, 논리적 연결이 무엇을 말하고 계신지 잘모르겠습니다. 4. 추가적으로 tcp 없이 데이터를 전송해서 서버가 닫혀있어 전송을 못받은 경우와 ack을 3번 주고 받은 경우에 ack을 주고 받는게 속도가 더 빠른가요? 질문을 바꿔서 tcp없이 데이터를 전송하는 그 자체로 해당 서버에서 데이터를 받았는지 안받았는지 체크할수 있는것 아닌가요? 근데 굳이 연결상태를 먼저 체크하고 보내는 이유가 궁금합니다. 보안이나 ack으로 체크하면 데이터 자체로 체크하는것 보다 속도가 빠르다 정도로 예상해봤습니다.
- 미해결모든 개발자를 위한 HTTP 웹 기본 지식
지속연결과 put 메서드 질문드립니다
HTTP에서 맨 처음에 클라이언트-서버가 연결하고 있으면 서버가 계속 연결을 유지해야 하니까 자원이 많이 낭비돼서 비 연결성으로 요청 -> 응답 -> 종료 이렇게 바꿨는데 이러면 너무 오래걸리니까 지속 연결을 사용한다는데 결국 지속 연결 사용하면 맨 처음 자원이 많이 낭비 되던 시절로 돌아간 건가요?
- 미해결모든 개발자를 위한 HTTP 웹 기본 지식
개발자님 프로토콜이란게 뭔가요?
프로토콜. 통신규약, 즉 규칙이란거는 매번 들어서 알겠는데 그래서 프로토콜이 뭔가는 아직도 모르겠 습니다. 규칙을 적어놓은 문서를 말하는건지, 설명해주신 목적지 ip와 출발지 ip를 코드로 적어서 어딘가에 담는 것을 말하는건지, 무슨 알고리즘을 말하는건지 모르겠습니다. 마찬가지로 패킷도 데이터를 패킷으로 보낸다는 것은 알겠는데 패킷이 실제로 무엇인지는 잘 모르겠습니다. 예를들어, 리스트 같은 구조체를 코드로 만들어서 거기의 내용을 채워서 보내는걸 패킷이라고 부르는건가요? 패킷이나 아이피의 속성값이 무엇으로 이루어졌는지 가 아닌 이 자체가 무엇이고 어떻게 쓰인다는지 감이 오지 않아서 질문남깁니다. 더 나아가 인터넷이 tcp ip프로토콜로 이루어져 있다. 전혀 이해해본적이 없는 개념입니다 ㅠ