spring security - How to have spring security context as child context

Framework & Platform/Spring 2014. 1. 9. 22:47


I'm trying to have spring security context as a parent context, so I could have url security on the servlet context file.

I have:

  <filter>
    <filter-name>springSecurityFilterChain</filter-name>
    <filter-class>org.springframework.web.filter.DelegatingFilterProxy</filter-class>
  </filter>
  <filter-mapping>
    <filter-name>springSecurityFilterChain</filter-name>
    <url-pattern>/*</url-pattern>
  </filter-mapping>
  <context-param>
    <param-name>contextConfigLocation</param-name>
    <param-value>
        classpath:/spring-security.xml
    </param-value>
  </context-param>
  <listener>
    <listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
  </listener>
  <servlet>
    <servlet-name>myapp-soap</servlet-name>
    <servlet-class>org.springframework.ws.transport.http.MessageDispatcherServlet</servlet-class>
    <init-param>
      <param-name>transformWsdlLocations</param-name>
      <param-value>true</param-value>
    </init-param>
  </servlet>

on web.xml, general security configuration on spring-security.xml and

<!-- Authorization configurations -->
<security:http auto-config="false" use-expressions="true"
    create-session="never"
    authentication-manager-ref="authenticationManager"
    entry-point-ref="authenticationEntryPoint">

    <security:custom-filter
        position="PRE_AUTH_FILTER" ref="serviceAuthenticationFilter"/>

    <security:intercept-url
        pattern="/GetForbiddenUrl" access="hasRole('roleThatDoesntExist')" />
    <security:intercept-url pattern="/**" access="permitAll" />
</security:http>
<!-- annotation security -->
<security:global-method-security pre-post-annotations="enabled"/>

on the myapp-soap-servlet.xml. It doesn't work but fails with

ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/my-app/v1/soap]] (ServerService Thread Pool -- 192) JBWEB000284: Exception starting filter springSecurityFilterChain:
org.springframework.beans.factory.NoSuchBeanDefinitionException: No bean named 'springSecurityFilterChain' is defined

However, if I move <security:http> part to spring-security root context configuration, everything works. Shouldn't it work the way I try? How can I get url-based security in my child context?

I also tried combining the context files into one, but the same problem seems to occur.

   
share|improve this question
 
Are you sure that your spring-security.xml is picked up by spring? –  Maksym Demidas Jun 4 '13 at 15:05
 
@MaksymDemidas yes, as moving the http part results in all directives being used, in both parnt and child context –  eis Jun 4 '13 at 21:40
add comment
up vote5down voteaccepted

The DelegatingFilterProxy will by default look in the root ApplicationContext which means by default you need to place your <http> configuration there (it is what creates the springSecurityFilterChain).

However, you can specify use that DelegatingFilterProxy a different ApplicationContext by specifying the contextAttribute for it to use. To do this update your web.xml as shown below

<filter>
    <filter-name>springSecurityFilterChain</filter-name>
    <filter-class>org.springframework.web.filter.DelegatingFilterProxy</filter-class>
    <init-param>
        <param-name>contextAttribute</param-name>
        <param-value>org.springframework.web.servlet.FrameworkServlet.CONTEXT.myapp-soap</param-value>
    </init-param>
</filter>

A similar example using Spring Security 3.2+'s AbstractSecurityWebApplicationInitializer can be seen below:

public class SecurityApplicationInitializer extends
        AbstractSecurityWebApplicationInitializer {

    @Override
    protected String getDispatcherWebApplicationContextSuffix() {
        // NOTE: if you are using AbstractDispatcherServletInitializer or
        // AbstractAnnotationConfigDispatcherServletInitializer You probably
        // want this value to be "dispatcher"
        return "myapp-soap";
    }

}

This works because it modifies the name of the ServletContext attribute that DelegatingFilterProxyuses to lookup the ApplicationContext. Instead of using the default value which discovers the rootApplicationContext it now uses the attribute that your MessageDispatcherServlet is using (thus pointing to the child context).

Note that MessageDispatcherServlet's (or any subclass of FrameworkServlet such asDispatcherServlet) stores the ApplicationContext in the ServletContext using the attribute name "org.springframework.web.servlet.FrameworkServlet.CONTEXT." + <servlet-name>where <servlet-name> is the name of the servlet. So in this instance, the attribute that must be configured is org.springframework.web.servlet.FrameworkServlet.CONTEXT.myapp-soap. If you changed the servlet-name from myapp-soap to spring-servlet, then you would useorg.springframework.web.servlet.FrameworkServlet.CONTEXT.spring-servlet instead.

PS I think the subject should read "How to have spring security context as child context"

share|improve this answer


출처 - http://stackoverflow.com/questions/16920243/how-to-have-spring-security-context-as-parent-context






DispatcherServlet만 사용 시에 DelegatingFilterProxy 등록 방법

Java 이야기/Spring 2011/06/19 00:52
편의상 반말을 사용 하겠습니다.

보통 서블릿 필터를 등록 할 때에는 필터 내부에서는 스프링 빈을 주입 받지 못해 많이 불편하다.

그래서 스프링에서 필터를 지원 해주는 클래스가 존재 하는데 그 클래스가 DelegatingFilterProxy 라는 클래스 이다.

보통을 그냥 서블릿 필터를 등록해서 사용하면되나 문제는 Spring security 프레임워크를 사용 시에는 필수 사용 하게되게된다.

 <filter>
  <filter-name>springSecurityFilterChain</filter-name>
  <filter-class>org.springframework.web.filter.DelegatingFilterProxy</filter-class>
 </filter>
 <filter-mapping>
  <filter-name>springSecurityFilterChain</filter-name>
  <url-pattern>/*</url-pattern>
 </filter-mapping>
<-- 이건 spring-security 설정시 필터 등록하는 부분 

이런 방식으로 web.xml에 필터 추가 하여 Spring security를 사용 할 수 있게 된다.

문제는 SpringMVC를 사용시에 문제가 되는데 

 <listener>
  <listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
 </listener>
<-- 이건 RootWAC 설정 부분

 <servlet>
  <servlet-name>SpringMVC</servlet-name>
  <servlet-class>org.springframework.web.servlet.DispatcherServlet </servlet-class>
  <load-on-startup>1</load-on-startup>
 </servlet>
 <servlet-mapping>
  <servlet-name>SpringMVC</servlet-name>
  <url-pattern>/</url-pattern>
 </servlet-mapping>
<-- DispatcherServlet 설정 부분 

RootWAC를 등록하면 문제가 되지 않지만 이것을 등록하지 않고 DispatcherServlet만 사용하여 spring-mvc를 구성할 때에는 위에서 말한 DelegatingFilterProxy 기능을 사용할 수가 없게 되는것이 었다.

No WebApplicationContext found: no ContextLoaderListener registered?
<-- RootWAC를 등록하지 않고 DispatcherServlet구성만 사용 했을 때 DelegatingFilterProxy 을 사용 하고자하면 발생하는 에러

그래서 spring security 사용 할 때에는 RootWAC도 필요 없이도 생성 해줘야 하는 문제가 생겨 버렸다. 

프레임워크 구성시 사용 하다보면 이렇게 두개의 WAC가 생성이 되어 버리면 공통인 부분은 RootWAC로 빈을 등록 시키고  springMVC를 타는 웹 컨트롤 부분은 DispatcherServlet으로 등록 해줘야한다. 

문제는 이 부분에서 애매하게 되어 버리는 경우 개발하면서 많이 생기는데 ( ex: DispatcherServlet 부분에 등록된 빈을 RootWAC에 등록된 빈에서 불러온다거나.. 등등) 그 때마다 에러나면서 안되는 것을 보면서 DelegatingFilterProxy 등록 때문에 꼭 이렇게 나누어야 하는지 회의감이 들었다.

그래서 여기저기 찾아 보고 DelegatingFilterProxy 클래스 내부를 훝어본결과 해결 방법을 찾게되었다.

먼저 스프링에 대한 모든 유용한 정보(?)가 있다는  토비님 블로그에서 해답을 찾았는데 

일단 DelegatingFilterProxy 클래스 안에서 

 protected WebApplicationContext findWebApplicationContext() {
  if (this.webApplicationContext != null) {
   // the user has injected a context at construction time -> use it
   if (this.webApplicationContext instanceof ConfigurableApplicationContext) {
    if (!((ConfigurableApplicationContext)this.webApplicationContext).isActive()) {
     // the context has not yet been refreshed -> do so before returning it
     ((ConfigurableApplicationContext)this.webApplicationContext).refresh();
    }
   }
   return this.webApplicationContext;
  }
  String attrName = getContextAttribute();
  if (attrName != null) {
   return WebApplicationContextUtils.getWebApplicationContext(getServletContext(), attrName);
  }
  else {
   return WebApplicationContextUtils.getWebApplicationContext(getServletContext());
  }
 }
<-- DelegatingFilterProxy.class 내부 내용 중 WAC를 찾는 메소드 부분

위의 매소드를 통하여 WAC를 찾고 있었다. 원래 기본 WebApplicationContextUtils.getWebApplicationContext(getServletContext()) 이 메소드를 통하여 찾아 올 수 있는 것은 RootWAC 밖에 없다고 한다. ( 자세한건 토비님 블로그 참조 )

그런데 거기서 DispatcherServlet 으로 등록한 WAC를 찾아 오기 위해서는 토비님 블로그에 자세하게 있지만 그대로 가져 오면 

FrameworkServlet.SERVLET_CONTEXT_PREFIX + 서블릿이름 

이 문자열을 WebApplicationContextUtils.getWebApplicationContext(getServletContext(), 이부분 );

이렇게 넘겨 주면 DispatcherServlet 으로 등록한 WAC를 가져 올 수 있다고 한다.

그래서 DelegatingFilterProxy.class 안을 더 확인 해본 결과 contextAttribute 속성에 그 문자열을 집어 넣으면 된다고 결론이 낫다.

FrameworkServlet.SERVLET_CONTEXT_PREFIX 이 상수 부분은 직접 사용 하지 못하여 내부 문자열을 확인 해본 결과"org.springframework.web.servlet.FrameworkServlet.CONTEXT." 이렇게 문자열을 가지고 있었다. 

그래서 서블릿이름과 조합해 본 결과 org.springframework.web.servlet.FrameworkServlet.CONTEXT.SpringMVC 이런식으로 매개 변수로 넘기면 될거라고 생각 했다.

 <filter>
  <filter-name>springSecurityFilterChain</filter-name>
  <filter-class>org.springframework.web.filter.DelegatingFilterProxy</filter-class>
  <init-param>
   <param-name>contextAttribute</param-name>
   <param-value>org.springframework.web.servlet.FrameworkServlet.CONTEXT.SpringMVC</param-value>
  </init-param>
 </filter>
<-- DelegatingFilterProxy 최종 설정 부분 

위의 설정을 저렇게 해주니 RootWAC 설정 부분을 제거 하고 DispatcherServlet 설정만 해주어도 에러 없이 실행이 잘 되었다.

물론 RootWAC를 사용 하는 사람은 상관없는 내용이지만 DispatcherServlet 하나만 사용하면서 Spring security 나 필터부분을 사용 하고자 하는 사람에게는 유용할것이라고 생각된다.

참고로 RootWAC를 가져 오기 위한 의 디폴트 속성은 
WebApplicationContext.ROOT_WEB_APPLICATION_CONTEXT_ATTRIBUTE 로 기술 되어 있었다 .

org.springframework.web.context.WebApplicationContext.ROOT 요부분이 넘어가는부분이 생략이 되어 있는듯하다.



출처 - http://sbcoba.tistory.com/8



저작자표시

'Framework & Platform > Spring' 카테고리의 다른 글

spring - @Scheduled  (0) 2014.02.11
spring data - mongoDB Date type  (0) 2014.01.15
spring security - javaConfig  (0) 2013.12.31
spring - apache POI example  (0) 2013.09.26
spring - util  (0) 2013.09.05
Posted by linuxism
,

web - SPDY

Web/Common 2014. 1. 9. 13:57


SPDY(스피디/speedy/로 발음)[1]는 웹 콘텐츠를 전송할 목적으로 구글이 개발한 개방형 네트워크 프로토콜이다.[1] 2012년 7월에 SPDY 개발 그룹은 인터넷 초안으로 이용 가능한 표준화 작업을 진행하고 있다고 발표했다.[2] HTTP 2.0의 첫 초안은 SPDY를 규격 초안 및 편집을 위한 작업 기반으로 사용한다.[3] SPDY에 구현되는 기능들은 크로미엄[4], 모질라 파이어폭스[5], 오페라[6], 아마존 실크, 인터넷 익스플로러[7]에 존재한다. SPDY는 웹 페이지 부하 레이턴시를 줄이고 웹 보안을 개선하는 목표 면에서 HTTP와 비슷하다. SPDY는 압축, 다중화, 우선 순위 설정을 통한 레이턴시 감소를 달성한다.[1] "SPDY"는 구글의 상표이며 두문자어는 아니다.[8]

같이 보기[편집]

참조[편집]

  1. ↑ 이동:가 나 다 SPDY: An experimental protocol for a faster web. 《Chromium Developer Documentation》. 2009년 11월 13일에 확인.
  2. 이동↑ SPDY Protocol on IETF. 2012년 2월 8일에 확인.
  3. 이동↑ Nottingham, Mark. First draft of HTTP/2. 《HTTP Working Group Mailing List》. 2 December 2012에 확인.
  4. 이동↑ SPDY on Google servers?. 2012년 2월 28일에 확인.
  5. 이동↑ Mozilla Bug 528288 - Implement SPDY protocol.
  6. 이동↑ Opera: Built-in support for the SPDY protocol. 2012년 11월 6일에 확인.
  7. 이동↑ IE11 SPDY/3 confirmed. 2013년 6월 25일에 확인.
  8. 이동↑ Google Permissions: Guidelines for Third Party Use of Google Brand Features. Google. September 30, 2011에 확인.

바깥 고리[편집]





SPDY (pronounced speedy)[1] is an open networking protocol developed primarily at Google for transporting web content.[1] As of July 2012, the group developing SPDY has stated publicly that it is working toward standardization (available as an Internet Draft).[2] The first draft of HTTP 2.0 is using SPDY as the working base for its specification draft and editing.[3] Implementations of SPDY exist in Chromium,[4] Mozilla Firefox,[5] Opera,[6] Amazon Silk, and Internet Explorer.[7] SPDY is similar to HTTP, with particular goals of reducing web page load latency and improving web security. SPDY achieves reduced latency through compression,multiplexing, and prioritization.[1] The name "SPDY" is a trademark of Google, and is not an acronym.[8]

Design[edit]

The goal of SPDY is to reduce web page load time.[9] This is achieved by prioritizing and multiplexing the transfer of web page subresources so that only one connection per client is required.[1][10] TLSencryption is nearly ubiquitous in SPDY implementations, and transmission headers are gzip-or DEFLATE-compressed by design[11] (in contrast to HTTP, where the headers are sent as human-readable text). Moreover, servers may hint or even push content instead of awaiting individual requests for each resource of a web page.[12]

SPDY requires the use of SSL/TLS (with TLS extension NPN), and does not support operation over plain HTTP.

Relation to HTTP[edit]

SPDY does not replace HTTP; it modifies the way HTTP requests and responses are sent over the wire.[1] This means that all existing server-side applications can be used without modification if a SPDY-compatible translation layer is put in place. When sent over SPDY, HTTP requests are processed, tokenized, simplified and compressed. For example, each SPDY endpoint keeps track of which headers have been sent in past requests and can avoid resending the headers that have not changed; those that must be sent are compressed.

The IETF working group for HTTPbis has released the draft of HTTP 2.0.[13] SPDY (draft-mbelshe-httpbis-spdy-00) was chosen as the starting point.[14][15]

Caching[edit]

The server push mechanism pushes content regardless of existing cache which can result in waste of bandwidth. The workaround is to use the server hint mechanism.[16]

Protocol support[edit]

For use within HTTPS, SPDY needs the TLS extension Next Protocol Negotiation (NPN),[17] thus browser and server support depends on the HTTPS library.

OpenSSL 1.0.1 or greater introduces NPN.[18] Patches to add NPN support have also been written for NSS and TLSLite.[19]

Protocol versions[edit]

SPDY is a versioned protocol. In its control frames there are 15 dedicated bits to indicate the version of the session protocol.

  • Version 1: version 1 of the SPDY protocol is not used anymore.[20]
  • Version 2: soon to be discontinued. Nginx supports spdy/2.[21] Firefox 28 and recent versions of Chrome drop support for SPDY version 2.[22][23]
  • Version 3: SPDY v3 introduced support for flow control, updated the compression dictionary, and removed wasted space from certain frames, along with other minor bug fixes.[11] Firefox supports SPDY v3 in Firefox 15.[24]
  • Version 3.1: SPDY v3.1 introduced support for session-layer flow control, and removed the CREDENTIALS frame (and associated error codes).[25] Firefox 27 has added SPDY 3.1 support.[26]

Browser support and usage[edit]

  • Firefox supports SPDY 2 from version 11, and default-enabled since 13 and later. (Also SeaMonkey version 2.8+.) SPDY protocol functionality can be (de)activated by toggling thenetwork.http.spdy.enabled variable in about:config.[5] Firefox 15 added support for SPDY 3.[24] Firefox 27 has added SPDY 3.1 support.[26] Firefox 28 will remove support of SPDY 2.[22]about:networking shows if a websites uses SPDY.

Server support and usage[edit]

As of April 2013, approximately 1% of all websites support SPDY.[35] Some Google services (e.g. Google search, Gmail, and other SSL-enabled services) use SPDY when available.[36] Google's ads are also served from SPDY-enabled servers.[37]

A brief history of SPDY support amongst major web players:

  • In March 2012, Twitter enabled SPDY on its servers, at the time making it the second largest site known to deploy SPDY.[38]
  • In March 2012, the open source Jetty Web Server announced support for SPDY in version 7.6.2,[39] while other open source projects were working on implementing support for SPDY, like node.js,[40][41]Apache (mod_spdy),[42] curl,[43] and nginx.[44]
  • In April 2012 Google started providing SPDY packages for Apache servers which led some smaller websites to provide SPDY support.[45]
  • In May 2012 F5 Networks announced support for SPDY in its BIG-IP application delivery controllers.[46]
  • In June 2012 NGINX, Inc. announced support for SPDY in the open source web server Nginx.[47]
  • Cloudflare is also providing a beta of SPDY on their servers (using Nginx) from June 2012, though users who would like to use/test it must be paying customers as SPDY is built on top of TLS, and only paying customers can use SSL/TLS Certificates.[48]
  • In June 2012, LiteSpeed Technologies announced support for SPDY on OpenLiteSpeed, their open source HTTP server.[49]
  • In July 2012 Facebook announced implementation plans for SPDY.[50] By March 2013 SPDY was implemented by some of their public web servers.[51]
  • In August 2012 WordPress.com announced support for SPDY (using nginx) across all their hosted blogs.[52]

See also[edit]

Portal iconIT portal
Portal iconSoftware portal
Portal iconInternet portal
Portal iconGoogle portal

References[edit]

  1. ^ Jump up to:a b c d e "SPDY: An experimental protocol for a faster web".Chromium Developer Documentation. Retrieved 2009-11-13.
  2. Jump up^ "SPDY Protocol on IETF". Retrieved 2012-02-08.
  3. Jump up^ Nottingham, Mark. "First draft of HTTP/2". HTTP Working Group Mailing List. Retrieved 2 December 2012.
  4. Jump up^ "SPDY on Google servers?". Retrieved 2012-02-28.
  5. ^ Jump up to:a b "Mozilla Bug 528288 - Implement SPDY protocol".
  6. Jump up^ "Opera: Built-in support for the SPDY protocol". Retrieved 2012-11-06.
  7. Jump up^ "IE11 SPDY/3 confirmed". Retrieved 2013-06-25.
  8. Jump up^ "Google Permissions: Guidelines for Third Party Use of Google Brand Features". Google. Retrieved September 30, 2011.
  9. Jump up^ "A 2x Faster Web". Official Google Chromium Blog. 2009-11-11. Retrieved 2009-11-13.
  10. Jump up^ Iljitsch van Beijnum (2009-11-12). "SPDY: Google wants to speed up the web by ditching HTTP". Ars Technica. Retrieved 2009-11-13.
  11. ^ Jump up to:a b "SPDY Protocol - Draft 3". Retrieved 25 August 2012.
  12. Jump up^ Mirko Lindner (13 November 2009). "Google stellt HTTP-Alternative SPDY vor". Retrieved 2011-10-21. (German)
  13. Jump up^ Nottingham, Mark. "What's next for HTTP". Retrieved 2012-03-31.
  14. Jump up^ WG Review: Hypertext Transfer Protocol Bis (httpbis)
  15. Jump up^ "HTTPbis Working Group Start To Consider HTTP/2.0". InfoQ. 2012-04-28. Retrieved 2012-08-09.
  16. Jump up^ "Server Push and Server Hints - The Chromium Projects". Chromium.org. Retrieved 2012-05-10.
  17. Jump up^ NPN protocol and explanation about its need to tunnel SPDY over HTTPS.
  18. Jump up^ Openssl 1.0.1 changelog.
  19. Jump up^ TLS Next Protocol Negotiation. Section: Implementations.
  20. Jump up^ SPDY Protocol - Draft 2: "Currently, the only valid string is "spdy/2" (spdy/1 isn't implemented anywhere anymore)".
  21. Jump up^ http://nginx.org/en/docs/http/ngx_http_spdy_module.html
  22. ^ Jump up to:a b "Bug 912550 - remove spdy/2 support". Retrieved 2013-12-14.
  23. Jump up^ https://code.google.com/p/chromium/issues/detail?id=303957
  24. ^ Jump up to:a b "Firefox 15 — Release Notes". Retrieved 3 September 2012.
  25. Jump up^ "SPDY Protocol - Draft 3.1". Retrieved 17 November 2013.
  26. ^ Jump up to:a b "Firefox Beta Notes Desktop". 2013-12-12. Retrieved 2013-12-14.
  27. Jump up^ Chromium SPDY client implementation.
  28. Jump up^ Chromium: SPDY proxy examples.
  29. Jump up^ List of Chromium Command Line Switches.
  30. Jump up^ Opera 12.10 Changelog
  31. Jump up^ "WebGL, SPDY/3, New Dev Tools, & More Confirmed For IE11 In Win 8.1". Microsoft News.
  32. Jump up^ "IE11 Changes". Microsoft.
  33. Jump up^ Paul Thurrott's Supersite for Windows: Microsoft Releases Internet Explorer 11 for Windows 7
  34. Jump up^ Ryan Paul (28 September 2011). "Amazon's Silk Web browser adds new twist to old idea". Retrieved 2011-10-21.
  35. Jump up^ Usage of SPDY for websites.
  36. Jump up^ spdy-dev mailing list: SPDY on Google servers?.
  37. Jump up^ Google Speeds Up Web-Page Downloads with SPDY Protocol - Cloud Computing - News & Reviews. eWeek.com (2011-06-20). Retrieved on 2013-11-21.
  38. Jump up^ Twitter Adopts SPDY.
  39. Jump up^ Jetty Feature SPDY.
  40. Jump up^ "indutny/node-spdy · GitHub". Github.com. Retrieved 2012-05-10.
  41. Jump up^ Fedor Indutny (2012-01-24). "What the $%@! is SPDY - blog.nodejitsu.com - scaling node.js applications one callback at a time". blog.nodejitsu.com. Retrieved 2012-05-10.
  42. Jump up^ "mod-spdy - Apache SPDY module - Google Project Hosting". Code.google.com. Retrieved 2012-05-10.
  43. Jump up^ "libspdy". daniel.haxx.se. 2011-10-18. Retrieved 2012-05-10.
  44. Jump up^ https://twitter.com/#!/nginxorg/status/192301063934705665.
  45. Jump up^ "mod_spdy - mod_spdy — Google Developers". Google. Retrieved 2012-05-10.
  46. Jump up^ F5 Helps Organizations Improve User Experience and Simplify Management with First Integrated SPDY Gateway | About F5 | F5 Networks. F5.com (2012-05-08). Retrieved on 2013-11-21.
  47. Jump up^ "Announcing SPDY draft 2 implementation in nginx". Nginx. 2012-06-15. Retrieved 2012-06-16.
  48. Jump up^ Introducing SPDY - CloudFlare Blog.
  49. Jump up^ OpenLiteSpeed 1.1 (With SPDY!) Retrieved 2013-08-12.
  50. Jump up^ Beaver, Doug. "HTTP2 Expression of Interest". W3C. Retrieved 15 July 2012.
  51. Jump up^ Finley, Klint. "Facebook Makes Itself a Bit More SPDY". Wired. Retrieved 18 March 2013.
  52. Jump up^ "Just enabled #SPDY for all http://WordPress.com -hosted sites.". 2012-08-28. Retrieved 2012-08-28.

External links[edit]



 출처 - http://ko.wikipedia.org/wiki/SPDY





SPDY는 무엇인가? 개발자Tip

2012.08.28 19:03

  

NHN Business Platform 웹플랫폼개발랩 박세훈

최근 Google의 SPDY 프로토콜을 Facebook에서도 지지하며 Facebook도 SPDY 구현을 시작했다는 기사가 발표됐습니다. 웹 속도를 빠르게 하기 위해 다양한 방법을 고안하고 제시하는 Google의 노력 중에서, 새로운 산업 표준을 만들 정도로 가장 빛을 보고 있는 것이 바로 SPDY가 아닐까 싶은데요. SPDY는 HTTP 2.0에 포함될 예정입니다.

SPDY는 'speedy'라는 단어를 기반으로 Google이 만든 조어로, Google이 자신들의 'Make the Web Faster' 노력의 하나로 제안한 새로운 프로토콜입니다. 이는 초창기 인터넷 환경에서 고안된 HTTP의 단점들을 보완하여, 지금과 앞으로의 인터넷 환경을 보다 효율적으로 이용할 수 있는 프로토콜로 제안된 것입니다.

이 글에서는 SPDY의 기능과 장점을 간단히 소개하고, SPDY 지원 현황을 살펴 본 후, SPDY 도입 시의 고려 사항에 대해 살펴보도록 하겠습니다.

너무 오래 버전 업이 없었던 HTTP

HTTP는 1991년에 0.9 버전이 처음 발표되었고, 1996년에 1.0 버전, 1999년에 1.1 버전이 나온 뒤로 10년이 넘는 시간 동안 전혀 변화가 없었다. 그러나 오늘 날의 웹 페이지는 1990년대의 웹 페이지에 비하여 그 규모와 페이지당 HTTP 요청 개수가 20배 가량 증가했다. 표 1은 Google I/O 2012에서 Google이 발표한 자료에서 발췌한 것이다.

표 1 2010년과 2012년의 평균 웹 페이지 규모 비교

 

평균 페이지 크기

페이지당 평균 요청 개수

평균 도메인 개수

2010년 11월 15일

702KB

74

10

2012년 5월 15일

1059KB

84

12

1996년도의 Yahoo 메인 페이지 용량은 34KB 정도였다. 이는 2012년 평균 웹 페이지 용량의 30분 1 수준이다.

1990년대와의 비교는 물론이고, 근자인 2010년과 2012년을 비교해도 상당한 차이가 있다. 초고속 인터넷 보급과 함께 점점 더 미려한 사용자 UX 덕분에 페이지 크기와 요청 개수의 평균 값이 증가하고 있는 것이다.

이와 같이 과거에 비해 달라진 오늘날의 웹 페이지의 특징을 정리하면 다음과 같다.

예전과 달라진 오늘 날의 웹 환경을 고려하여 Google에서는 HTTP를 보완한 SPDY 프로토콜을 발표하게 된 것이다.

이 SPDY 프로토콜은 특히 전송 지연(latency) 문제의 해결에 주로 집중하고 있다.

SPDY 특징

전통적인 TCP/IP 계층 모델과 비교하여 SPDY의 계층을 표현하면 그림 1과 같다.

7f3afc38487a8fb32af30c980046018c.png

그림 1 HTTP와 SPDY 비교

SPDY의 특징을 간단히 살펴보자.

따라서 HTTPS로 작성된 웹 사이트만 적용 가능하다.

TLS는 SSL(Secure Sockets Layer)의 다음 버전이다. 같은 프로토콜의 예전 버전 이름과 현재 버전 이름이므로 종종 혼동되어 사용되며, 이 기사에서도 TLS와 SSL을 구별해서 사용하지는 않는다.

HTTP 헤더에는 요청마다 반복되는 내용이 매우 많으므로 헤더 압축만으로도 충분한 성능 향상 효과를 얻을 수 있다. Google의 발표 자료에 따르면 HTTP 헤더 압축으로 최초 요청 시에도 10~35%의 크기를 감소시킬 수 있고, 여러 번 요청이 있을 경우에는(long-lived 커넥션) 80~97%까지 헤더 크기를 감소시킬 수 있다고 한다. 또한 모바일과 같이 업로드 대역폭이 상대적으로 작은 경우에는 이런 HTTP 헤더 압축 방법이 특히 유용하다. 오늘날의 HTTP 헤더는 평균 2KB 가량이고, 점점 더 커지는 추세이기 때문에 HTTP 헤더 압축의 가치는 앞으로는 더 커질 것이라고 보고 있다.

프레임을 텍스트가 아닌 바이너리로 구성하므로 파싱이 더 빠르고, 오류 발생 가능성이 낮다.

하나의 커넥션 안에서 다수의 독립적인 스트림을 동시에 처리한다. 따라서 하나의 커넥션에서 한 번에 하나만의 요청을 처리하며, 요청에 대한 응답이 순차적으로 이뤄지는 HTTP와 달리 적은 수의 커넥션으로 다수의 요청, 응답을 동시에 처리할 수 있다. 또한 FIFO(First In, First Out)로 처리되기 때문에 하나가 지연되면 나머지 응답도 모두 지연되는 HTTP 파이프라이닝(pipelining)과는 달리, 각각의 요청, 응답이 모두 독립적으로 처리된다.

한 스트림이 진행 중이더라도 다른 스트림이 끼어드는(interleaving) 것을 허용하고 스트림의 우선순위 설정도 지원하므로, 우선순위가 낮은 데이터 전송 도중에 우선순위가 높은 데이터가 끼어들어서 더 빨리 전달되게 할 수 있다.

Comet, 롱 폴링(long-polling) 같은 것과는 달리 클라이언트의 요청이 없어도 서버에서 콘텐츠를 직접 push할 수 있다. inlining 같은 방법과는 달리 리소스 캐싱이 가능하며, inlining과 같거나 더 적은 대역폭을 사용한다. 다만 server push를 구현할 때에는 웹 서버 애플리케이션 로직에 대한 추가 구현이 필요하다.

server push와 같이 추가 구현을 요구하는 기능을 제외하면, SPDY 적용 자체를 위해 웹 사이트 자체가 바뀌어야 할 필요는 없다. 다만 브라우저와 서버가 SPDY를 지원해야만 한다. SPDY는 브라우저 사용자에게 완전히 투명하게 적용 가능하다. 즉, spdy:// 같은 프로토콜 scheme이 없다. 또한 브라우저에서도 SPDY 프로토콜 사용 여부에 대한 어떤 표시도 하지 않는다.

이와 같은 특징들을 가지고 HTTP와 SPDY의 차이점을 표로 나타내면 다음과 같다.

표 2 HTTP(1.1)와 SPDY 비교

 

HTTP

SPDY

Secure

Not Default

Default

Header Compression

No

Yes

Multiplexing

No

Yes

Full-Duplex

No

Yes

Prioritization

No(브라우저 자체 휴리스틱 사용)

Yes

Server Push

No

Yes

DNS Lookup

More

Less

Connections

More

Less

(자세한 내용은 Google I/O 2012 콘퍼런스 자료 36쪽을 참조한다.)

결국, SPDY는 HTTP의 데이터 전송 포맷과 커넥션 관리 부분을 고쳐서 TCP 커넥션을 보다 효율적으로 쓰도록 만든 것이라고 볼 수 있다.

Google의 SPDY Whitepaper(http://www.chromium.org/spdy/spdy-whitepaper/) 페이지의 'Table 1: Average page load times for top 25 websites' 표를 통해 SPDY가 HTTP+SSL에 비해 39~55%의 속도 향상을 보인다는 점을 확인할 수 있다.

왜 TLS를 필요로 하는가?

TLS 사용으로 인해 암호화/복호화 작업으로 인한 전송 지연이 발생함에도, 왜 SPDY는 TLS를 사용하고 있는가? 이 질문에 대해 Google의 SPDY Whitepaper에서는 다음과 같이 이유를 밝히고 있다.

"장기적으로 보아 웹 환경에서 보안성은 점점 더 강조될 것이므로, SPDY의 하위 프로토콜로 TLS를 지정하여 향후 더 나은 보안성을 얻고자 한다.

현재 네트워크 인프라와의 호환, 즉 기존의 프록시를 거치는 통신과 호환성 문제가 발생하지 않도록 하기 위해 TLS가 필요하다."

이와 같은 이유가 있으나, 실제 SPDY의 구현을 살펴보면 TLS의 NPN(Next Protocol Negotiation) 확장 기능에 SPDY가 크게 의존하고 있음을 알 수 있다. 이 TLS NPN 확장은 서버의 443 포트로 들어온 요청이 SPDY인지 여부 및 요청에서 사용하고 있는 SPDY 버전을 판별하여 이후의 통신을 SPDY로 처리할지 판단할 수 있게 한다. 만약 TLS NPN이 없다면 SPDY 사용을 위해 추가적인 RTT(round-trip time)가 필요할 것이다.

표준화 노력

SPDY는 공개된 프로토콜로 개발되고 있으며 HTTP/2.0의 한 방식으로 IETF(Internet Engineering Task Force)에 제안되어 있다. SPDY는 Google Chromium 프로젝트의 하위 프로젝트로 Chromium 클라이언트 구현 및 서버 도구는 모두 오픈소스로 개발되고 있다.

SPDY의 미래

SPDY는 현재 draft 3까지 발표됐으며, draft 4가 제작 중이다. draft 4에서 추가될 가능성이 높은 기능은 다음과 같다.

  • Name resolution push
  • Certificate data push
  • Explicit proxy support

SPDY의 최종 목표는 하나의 페이지를 '하나의 커넥션 설정 시간 + 바이트/대역폭 시간' 내에 서비스하는 것이다.

SPDY 지원 브라우저, 서버, 라이브러리, 웹 서비스

현재 다양한 브라우저와 서버가 SPDY를 지원하고 있으며, SPDY를 제안한 Google은 이미 자사의 거의 모든 서비스를 SPDY로 제공하고 있다. 이들 SPDY 지원 브라우저, 서버, 라이브러리, 서비스 등을 정리해 본다.

SPDY 지원 브라우저

2012년 7월 현재, SPDY를 지원하는 브라우저 목록은 다음과 같다.

  • Google Chrome/Chromium

Chrome과 Chromium은 초기 버전부터 SPDY를 지원하고 있다. 다음 URI를 입력하면 현재 Chrome/Chromium에서 연결 중인 SPDY 세션을 확인할 수 있다. chrome://net-internals/#events&q=type:SPDY_SESSION%20is:active 예를 들어www.gmail.com에만 들어가도 여러 개의 SPDY 세션이 생성되는 것을 확인할 수 있다. Android 용의 모바일 Chrome도 SPDY를 지원한다.

  • Firefox 11과 그 이후 버전

11 버전부터 SPDY를 지원하기는 하지만 기본 설정으로 제공하지는 않았고, 13 버전부터 기본 설정으로 제공하고 있다. Firefox 설정을 표시하는 URI인 about:config를 입력하고 network.http.spdy.enabled 항목을 보면 SPDY 지원이 활성화됐는지 확인할 수 있다. Android용의 모바일 Firefox 14 버전도 SPDY를 지원한다.

  • Amazon Silk

Android 기반 eBook인 Kindle Fire에 탑재된 Silk 브라우저는 SPDY를 지원하고 있다. Amazon EC2 서비스와 SPDY를 이용해 통신한다.

  • Android 3.0 이상의 기본 브라우저

Android 3.0(Honeycomb), 4.0 (Ice Cream Sandwich)의 기본 브라우저는 SPDY를 지원한다.

다음 URL에서 SPDY를 지원하는 브라우저에 대한 상세 정보를 확인할 수 있다.

SPDY 지원 서버 및 라이브러리

주요 웹 서버와 애플리케이션 서버에서 SPDY 지원을 활성화하고 있으며, SPDY를 구현한 라이브러리도 다양하게 개발되고 있다.

SPDY를 사용하는 서비스

앞서 언급한 것처럼 Google은 검색뿐만 아니라 Gmail, Google+ 등 자사의 거의 모든 서비스를 https로 전환하여 SPDY로 제공하고 있다. 또한 Google App Engine도 https를 사용하는 경우에는 SPDY를 지원한다. Twitter도 https로 서비스를 제공하면서 SPDY를 사용하고 있다.

그러나 실제로 현재의 수많은 웹 사이트 중에서 SPDY를 사용하는 사이트는 그다지 많지 않다. Netcraft의 2012년 5월 조사(http://news.netcraft.com/archives/2012/05/02/may-2012-web-server-survey.html)에 의하면 총 6.6억 개의 웹 사이트 중에서 339개 만이 SPDY를 사용하고 있다고 한다. 즉, 아직은 Google과 Twitter 외에는 SPDY를 사용하는 주요 사이트는 거의 없다고 할 수 있다.

SPDY가 그다지 효율적이지 않은 경우

SPDY가 항상 빠른 것은 아니다. 상황에 따라 SPDY로 얻을 수 있는 성능 이점이 거의 없을 수도 있다. 그런 상황들을 정리하면 다음과 같다.

  • HTTP만 사용하는 경우

SPDY는 반드시 SSL을 필요로 하므로 SSL 핸드셰이크 시간이 추가적으로 필요하다. 따라서 HTTP로 개발된 사이트를 SPDY 지원을 위해 HTTPS로 변경하는 경우 SSL 핸드셰이크 처리 시간으로 인해 뚜렷하게 성능 향상이 이뤄지지 않을 수도 있다.

  • 도메인이 많은 경우

SPDY는 도메인별로 동작한다. 즉 커넥션은 도메인 개수만큼 필요하고, 요청을 multiplexing하는 기능도 하나의 도메인 안에서만 가능하다. 또한 모든 도메인이 SPDY를 지원하게 만들기 어려우므로 도메인이 많은 경우에는 SPDY의 장점이 나타나기 어려워진다. 특히 CDN에서 SPDY를 지원하지 않는 경우에는 SPDY로 인한 성능 향상을 기대하기가 어렵게 된다.

  • HTTP가 병목이 아닌 경우

모든 웹사이트에서 HTTP가 병목으로 작용하는 것이 아니다. 다른 리소스 다운로드를 먼저 해야 다음 리소스를 다운로드할 수 있게 되어 있는 등의 이유로 대부분의 페이지에서 HTTP는 병목이 아닌 경우가 많다.

  • RTT가 작은 경우

SPDY는 RTT가 큰 경우에 더 큰 효율을 얻을 수 있다. IDC 내의 서버 간 통신처럼 RTT가 매우 작은 경우에는 이점이 별로 없다.

  • 페이지 내의 리소스가 매우 적은 경우

6개 이하의 리소스를 가지는 페이지라면 커넥션 재사용의 가치가 떨어지므로 이점이 별로 없다.

SPDY를 도입하는 경우 해야 할 일

SPDY를 최대한 효율적으로 적용하려면 다음과 같은 작업이 필요하다.

애플리케이션 레벨

  • 하나의 커넥션만 사용한다.

SPDY 성능을 위해서 그리고 효율적인 인터넷 리소스 사용을 위해서는 가능한 한 적은 수의 커넥션을 사용하는 것이 유리하다. SPDY를 사용할 때, 적은 수의 커넥션을 사용해야 데이터를 더 나은 방법으로 패킷에 넣을 수 있고, 헤더 압축 효율이 좋아지며, 커넥션 상태를 덜 확인하고, 핸드셰이크도 적게 하는 등의 이득이 있다. 또한 인터넷 리소스 면에서는 커넥션 개수가 적어야 TCP 효율이 좋아지고 Bufferbloat 현상을 감소시킬 수 있다.

참고

Bufferbloat: 라우터나 스위치에서 패킷을 너무 오래 버퍼링하기 때문에 전체 네트워크의 전송 지연(latency)이 높아지고 처리량(throughput)도 줄어드는 현상을 말한다. 가능한 패킷을 폐기하지 않아야 한다는 인식과 계속 낮아지는 메모리 가격 때문에 라우터나 스위치의 버퍼 크기는 계속 커졌고, 이로 인해 가급적 빨리 폐기돼야 할 패킷이 더 오래 살아남게 됐다. 결국 TCP 혼잡 회피 알고리즘을 방해하여 오히려 전체 네트워크 성능이 낮아지는 결과를 만든 것이다.

  • hostname sharding을 피한다.

hostname sharding은 흔히 웹 애플리케이션에서 브라우저의 동시 다운로드 개수 제한(일반적으로 hostname당 6개)을 피하기 위해 사용하는 일종의 편법이다. 앞서 설명한 단일 커넥션 사용을 권장하는 이유 때문에 SPDY를 쓰는 경우에는 hostname sharding이 불필요하다. 더구나 hostname sharding은 추가적인 DNS 쿼리를 발생시키고, 애플리케이션을 더 복잡하게 만든다.

  • inlining 대신에 server push를 사용한다.

inlining은 웹 애플리케이션에서 RTT를 줄이기 위해 사용한다. 그러나 inlining은 웹 페이지가 보다 덜 캐시되게 하고 base64 인코딩 때문에 웹 페이지 크기를 크게 만든다. 직접 콘텐츠를 push하는 SPDY server push 기능을 사용하면 이로 인한 문제를 피할 수 있다.

  • 요청 우선순위를 사용한다.

SPDY의 기능 중에 요청 우선순위 기능을 사용해서 클라이언트가 서버에 리소스의 상대적인 우선순위를 알리도록 할 수 있다. 일반적으로 적용할 수 있는 간단한 휴리스틱 우선순위로는 'html > js, css > *'를 생각해 볼 수 있다.

  • 적절한 SPDY 프레임 크기를 사용한다.

SPDY 스펙에서 큰 크기의 프레임을 허용하지만, 때때로 작은 프레임이 바람직한 경우도 있다. 프레임이 작은 경우에 프레임 interleaving이 더 잘 동작하기 때문이다.

SSL 레벨

  • 보다 작고 완전한 인증서 체인을 사용한다.

인증서 체인의 크기는 커넥션 초기화 성능에 상당한 영향을 미친다. 인증서 체인 내의 인증서가 많을수록 인증서 유효성 검증에 더 오랜 시간이 걸리고 initcwnd 내의 공간을 더 많이 차지하게 때문이다. 또한 서버가 완전한 인증서 체인을 제공하지 않는 경우에는 클라이언트는 중간에 있는 인증서를 가져오기 위해 추가적인 RTT를 사용하게 된다. 결국 크고 불완전한 인증서 체인을 사용할수록 애플리케이션이 커넥션을 사용할 수 있게 되기까지 더 오랜 시간이 걸리게 된다.

참고

initcwnd: TCP initial congestion window, TCP 혼잡 제어 알고리즘에서 사용되는 초기값. congestion window는 TCP 혼잡 제어 알고리즘에 따라 송신 측에서 크기를 조절하는 window로서, 수신 측에서 크기를 제한하는 일반적인 TCP window와는 다르다.

  • 쓸 수 있다면 와일드카드(wildcard) 인증서(*.naver.com 같은 형태의 인증서)를 사용한다.

와일드카드 인증서를 사용할 수 있다면 커넥션 개수가 줄고, SPDY의 커넥션 공유를 사용할 수 있게 된다. 다만, 와일드카드 인증서는 인증 기관에서 제공하는 것이므로 인증 기관과의 협의 및 추가적인 비용이 발생할 수 있다.

  • SSL 쓰기 버퍼의 크기가 너무 크지 않게 설정한다.

SSL 쓰기 버퍼가 너무 크면 TLS 애플리케이션 record는 여러 개의 패킷에 걸쳐진다. 애플리케이션은 전체 TLS 애플리케이션 record가 완성되어야 처리할 수 있으므로 여러 개의 패킷에 걸쳐진 record는 추가적인 전송 지연을 유발한다. Google 서버들은 2KB 크기의 버퍼를 사용하고 있다.

TCP 레벨

  • 서버의 initcwnd는 최소 10 이상으로 설정한다.

initcwnd는 페이지의 최초 로딩 시간에 영향을 주는 주된 병목이다. HTTP만 쓴다면 여러 개의 커넥션을 동시에 열어서 'n × initcwnd'의 초기 congestion window 크기를 달성하는 형태로 이 문제를 회피할 수 있으나, SPDY에서는 단일 커넥션이 유리하므로 처음부터 initcwnd를 크게 하는 것이 좋다. 오래된 Linux 커널은 이 값이 2~3 정도의 값으로 고정되어 있고 이를 조절할 방법을 제공하지 않고 있다. 처음 이 값을 고려할 때의 TCP 네트워크 신뢰성과 대역폭에 따라 정해진 값이므로 현대의 보다 안정적이고 높은 대역폭의 TCP 네트워크에는 적합하지 않은 값이다. 최신 Linux 배포판은 10 이상의 기본 값을 사용하고 있다. Linux 커널 2.6.18부터 이 값을 조절할 수 있다고 알려져 있으나 실제 동작 여부는 Linux 배포판에 따라 다르므로 주의가 필요하다.

  • tcp_slow_start_after_idle 설정을 끈다.

Linux 기본 설정은 tcp_slow_start_after_idle을 1로 설정하고 있는데, 이는 커넥션이 유휴(idle) 상태가 되면 congestion window를 다시 initcwnd 크기로 떨어뜨려서 TCP Slow Start를 다시 실행하게 한다. 이는 SPDY의 단일 커넥션의 이점을 죽이는 일이므로 이 설정을 꺼야 한다. sysctl 명령어를 이용해서 변경할 수 있다. HTTP keepalive 사용 시에도 이 설정을 끄는 것이 유리하다.

참고

TCP Slow Start: 처음에는 initcwnd 크기의 congestion window로 패킷을 보내면서 점점 congestion window 크기를 키워 네트워크가 허용하는 최대값 혹은 수신 측의 TCP window까지 키우는 것을 TCP Slow Start라 한다. initcwnd 값이 작으면 네트워크가 허용하는 최대 크기까지 도달하는 동안 더 많은 Round-Trip이 필요하므로 페이지 최초 로딩 시간이 더 길어진다.

마치며

이상에서 살펴본 바와 같이 SPDY를 실제로 도입하기에는 다양한 고민과 애플리케이션 및 서버 수정이 필요하다. 특히 도입에 들어가는 비용을 생각하지 않을 수 없는데, SPDY를 아직 지원하지 않는 Tomcat으로 작성된 웹 애플리케이션이라면 웹 애플리케이션 서버를 바꾸는 비용을 고려해야 하며, Server Push 기능의 추가 구현에 따른 비용도 생각해야 한다.

이 같은 SPDY 도입 자체 비용을 제외하고 당장 실제 서비스에서 SPDY 도입을 시도한다면 무엇을 가장 먼저 고려해야 할까? 3가지를 꼽아 본다.

  • 이미 HTTPS를 사용하는 서비스여야 한다

HTTP만 사용하는 서비스는 SPDY의 이득이 적고, SSL 도입에 따른 추가 비용이 발생한다.

  • Linux 커널을 교체할 수 있어야 한다.

initcwnd 조절로 얻는 성능상의 차이가 크기 때문에, 가급적 initcwnd가 조절 가능하거나 10 이상의 기본 값을 가진 Linux로 교체할 수 있어야 한다. CentOS의 경우 5.6 버전까지는 initcwnd 조절이 되지 않는다. 6.1부터 조절 가능하고, 6.2부터는 기본 값 10을 가지고 있다.

  • SPDY 지원 브라우저 사용자의 비율을 고려한다.

국내 서비스에서는 아직도 SPDY를 지원하지 않는 Internet Explorer 사용자가 태반이다. 모바일에서도 iOS는 아직 SPDY를 지원하지 않으며, Android는 3.0부터 지원을 시작하고 있다. 따라서, SPDY 지원 브라우저 사용자가 충분히 많아지기 전에는 SPDY의 성능 향상으로 얻는 이익과 SPDY 도입 비용을 잘 비교해야 할 것이다.

868106bceee131067f11c0b151e838de.jpg
NBP 웹플랫폼개발랩 박세훈
SI에영화 <코드명 J>의 원작 소설 이 발표된 것은 1981년이다. 저자인 윌리엄 깁슨은 대량의 데이터를 전달하려면 사람의 두뇌를 써야 할 것이라고 생각했다. 30년이 지나 사람은 두뇌를 사용하는 대신 손톱보다 작고 훨씬 대용량인 메모리카드를 만들어냈다. IT 기술이 이렇게 빠르게 발전하고 그만큼 데이터양도 늘어나고 있지만 메모리카드와 비교도 안 되게 좁은 필자의 두뇌에는 아직도 채워야 할 내용이 많은 것 같다. 그래서 언제나 무언가를 채우기 위해 돌아다니고 두리번거리고 있다.


출처 - http://en.wikipedia.org/wiki/SPDY








저작자표시

'Web > Common' 카테고리의 다른 글

web - tomcat gzip config  (0) 2014.02.07
web - HATEOAS  (0) 2014.01.12
해상도  (0) 2013.11.19
ie - 저장된 페이지의 새 버전 확인 > 자동 설정 상태에서 클라이언트 캐싱 제어  (0) 2013.10.09
web - 반응형(responsive) 웹  (0) 2013.09.14
Posted by linuxism
,

open source issue and bug tracking software

OpenSource/Common 2014. 1. 9. 00:57



48down votefavorite
15

What are the open-source alternatives of JIRA?

  
share|improve this question
3 
Note that JIRA is open-source –  rds Mar 1 '13 at 15:10
7 
I wish the "closed" status could be down-voted. –  Donald Taylor Aug 11 '13 at 21:48
add comment

closed as not constructive by Kev Sep 26 '11 at 15:22

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.If this question can be reworded to fit the rules in the help center, please edit the question.

up vote44down voteaccepted

There is an excellent overview (and comparison) on wikipedia. You might have a look therehttp://en.wikipedia.org/wiki/Comparison_of_issue-tracking_systems

Francis

share|improve this answer
add comment
up vote6down vote

Mantis and Redmine to name a few others. RedMine is really nice as it integrates with version control as well.

share|improve this answer
add comment
up vote3down vote

Bugzilla is a very active open source alternative http://www.bugzilla.org/about/

share|improve this answer
1 
Bugzilla is a bugtracker, not as powerfull as JIRA. –  guerda Nov 11 '10 at 9:41
1 
and what is JIRA... an ISSUE tracker :-) don't get me wrong I hold jira in a high praise, but when i look at the pricing it is not justified at least according to me. –  user10398 Nov 12 '10 at 4:23
add comment
up vote1down vote
  1. Bugzilla
  2. Trac

are the ones that are worth mentioning which integrate well with svn and some tools (Basically giving out an XML RPC extension point).

share|improve this answer
3 
nowadays, less and less people cares about SVN. It's the GIT era now. –  Shengjie Aug 15 '13 at 1:31
2 
@Shengjie I hate GIT. and so many other developers –  Dejel Aug 19 '13 at 10:12
1 
@Odelya that doesnt make Shengjie's statement invalid ;) Git is massively popular due to the way it decentralises a project. Just because you may not like it, that does not mean its not more popular than the alternative. –  RickM Aug 23 '13 at 15:31
add comment
up vote0down vote

A commercial JIRA license gives you the full source for JIRA. Such licenses start at $10. Or is there some other reason you need open-source?

share|improve this answer
 
No, I was just evaluating other options. I use JIRA on daily basis was just curious about other such tools. – Asad Khan Nov 10 '10 at 16:13
2 
As long as you've posted the 'teaser rate', can you publish the typical prices? –  user331465 Nov 11 '10 at 15:52
 
All the prices are public at atlassian.com/software/jira/pricing.jsp –  mdoar Nov 11 '10 at 16:12
2 
so that's just costly for anything sensible to get done. –  user10398 Nov 12 '10 at 4:17 
8 
Why use Open Source? Seriously? You imply with your reply that the only reason to use Open Source software is its cost advantage (i.e. free as in free beer). There are many, many other reasons to use Open Source software. You should really read THIS and this. –  waveslider Jun 27 '12 at 14:10 
show 1 more comment



출처 - http://stackoverflow.com/questions/4141061/opensource-jira-alternatives





저작자표시

'OpenSource > Common' 카테고리의 다른 글

redmine - bitnami redmine 한글 파일명, 디렉토리명 깨짐  (2) 2015.06.18
opensource - load balancing Software  (0) 2014.04.10
elasticsearch 사용  (0) 2014.01.08
activemq - MessageListener 구현  (0) 2013.04.14
Lisog - Open Source Business Alliance  (0) 2013.03.25
Posted by linuxism
,

티스토리툴바